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This series is directed to health care professionals leading the transformation of 
health care by using information and knowledge. For over 20 years, Health 
Informatics has offered a broad range of titles: some address specific professions 
such as nursing, medicine, and health administration; others cover special areas of 
practice such as trauma and radiology; still other books in the series focus on 
interdisciplinary issues, such as the computer based patient record, electronic health 
records, and networked health care systems. Editors and authors, eminent experts in 
their fields, offer their accounts of innovations in health informatics. Increasingly, 
these accounts go beyond hardware and software to address the role of information 
in influencing the transformation of health care delivery systems around the world. 
The series also increasingly focuses on the users of the information and systems: the 
organizational, behavioral, and societal changes that accompany the diffusion of 
information technology in health services environments. 

Developments in health care delivery are constant; in recent years, bioinformatics 
has emerged as a new field in health informatics to support emerging and ongoing 
developments in molecular biology. At the same time, further evolution of the field 
of health informatics is reflected in the introduction of concepts at the macro or 
health systems delivery level with major national initiatives related to electronic 
health records (EHR), data standards, and public health informatics. 

These changes will continue to shape health services in the twenty-first century. 
By making full and creative use of the technology to tame data and to transform 
information, Health Informatics will foster the development and use of new 
knowledge in health care. 
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Preface to the Third Edition 


This third edition contains significant changes to the book’s first edition in 2004 and 
also to its second edition in 2011. Of course, there has been progress in the method- 
ology and technology of processing and storing data, information, and knowledge, 
having an impact on technologies of health information systems and on their man- 
agement. In addition to this progress, there was an important trend from primarily 
institution-centered views on information systems, with hospital information sys- 
tems as the major instance, to patient-centered views on health information systems. 
When also including prevention as a relevant part of health care, this even leads to 
person-centered views with the respective requirements. 

Having this in mind, the structure of this third edition needed to be changed. We 
first had to introduce life situations and their context concerning health and health 
care in order to understand the various demands on health information systems 
(Chap. 1). Then, as in previous editions, basic concepts are introduced (Chap. 2). 
The three main chapters of this book deal with technology perspectives (Chap. 3) 
and management perspectives (Chap. 4) of health information systems as well as 
with how to assess their quality (Chap. 5). A new chapter had to be added on infor- 
mation systems for specific health care and research settings (Chap. 6). Although 
hospitals and hospital information systems remain highly relevant instances of 
health care facilities and health information systems, this chapter also includes vari- 
ous other health care facilities as well as medical research institutions. Last but not 
least, health care settings in personal environments such as a person’s home or 
workplace are considered as well as perspectives concerning transinstitutional 
health information systems of states and regions. New to this edition are solutions 
to the exercises. As in previous editions, we included a glossary (in the first and 
second edition called a thesaurus), listing all relevant terms introduced and used in 
this book. Both the solutions to the exercises and the glossary are part of the back 
matter of the book. 

We cordially want to thank everyone who helped us to write this third edition. It 
is impossible for us to list even the most important persons here, be they users or 
managers of such information systems, collaborators in projects on health informa- 
tion systems, or decision-makers in health care settings, from politics and from 
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governmental institutions. We would like to express our special thanks to all of our 
colleagues who contributed to this book and to the colleagues in our working groups 
and institutes. Thanks as well to the people who contributed to the photos in the 
book. Not least, we want to thank the students and teachers who use this textbook, 
in particular those students and teachers who participated in our international Frank- 
van Swieten Lectures on strategic management in health information systems. Both 
the students and the teachers kept asking critical questions and drew our attention to 
incomplete and indistinct arguments. 

Finally, we want to note that there was again a change of authors. M.M. and 
B.S. joined the team of authors. Birgit Brigl and Nils Hellrung asked to step down 
as their new and demanding responsibilities made it difficult for them to continue. 


Leipzig, Germany Alfred Winter 
Hall in Tirol, Austria Elske Ammenwerth 
Braunschweig, Germany Reinhold Haux 
Hannover, Germany Michael Marschollek 
Berlin, Germany Bianca Steiner 


Leipzig, Germany Franziska Jahn 


About the Book 


How medicine and health care must, should, may, can, and want to act and, 
accordingly, what health information systems must, should, may, can, and 
want to support and enable 


For medicine, especially for health care, its self-reflective character seems to be 


of particular importance to me: incorporated into our socio-cultural space, it must 
always consider in which image of humanity, in which range of cultural values 
between health and illness, between “normality” and “abnormality,” it 


must act: This concerns the question of urgency for patients. 

should act: This concerns practical aspects for patient care and medical 
self-conception. 

may act: This concerns individual, socio-ethical, moral, and legal dimensions. 
can act: This concerns medical competence and institutionalized dimensions of 
health care systems. And, finally, 

wants to act: This concerns the commitment of the people involved—from health 
care professionals (such as physicians and nurses) to informal caregivers and to 
the patients themselves—taking into account their “involvements.” 


With these modalities of action, medicine is not only committed to the present 


status but also to the prognosis (of current diseases and developments of medicine 
and society). 


Professor Dr. med. Klaus Gahl 
From a correspondence with Dr. Gahl in April 2020 (translated from German). 
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Chapter 1 A 
Introduction gree 


1.1 Motivation and Objective of the Book 


Which technologies are appropriate for building health information systems? How 
can they be managed? How to assess their quality? The objective of this book is to 
provide answers to these questions. 

Health is one of the key components of our lives. And good health care is an 
important prerequisite for good health. Well-built and well-managed health infor- 
mation systems constitute an essential part of providing good health care. Health 
care is delivered for people by people. Health care starts when people are born (even 
earlier) and ends when people pass away. Sometimes, the relative share of health 
care in our lives appears negligible, for example, when we are in good health, living 
our “normal daily lives.” Sometimes, the relative share of health care is intensive, 
for example, for persons suffering from a severe acute disease and as inpatients in 
hospitals. Sometimes, it is in between, for example, for persons with chronic dis- 
eases needing medication or other therapeutic measures on a regular basis. 

The authors of this book have been involved in managing health information 
systems for many years, some of us for decades. Managing information systems 
also includes building and assessing components of such systems, as will be 
explained later. We do this mainly in research and education, but always with 
close links to practice. We also advise health care facilities as well as governments 
and other authorities. During all these years, we have seen information systems 
that contribute well to the diagnosis and therapy of patients by providing good 
support to health care professionals as well as to the patients themselves. We have 
also seen information systems that produce an unnecessary workload for physi- 
cians and nurses or fail to appropriately deliver information that would have been 
relevant for good decisions. 

We, the authors of this book, believe that managing health information systems 
in the current era of digitization must be approached differently than in the past. In 
particular, in order to provide answers to the questions raised at the beginning, we 
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need an understanding of how information systems in the context of health and 
health care relate to the various life situations. 

This is why this introductory chapter is on such life situations and on the (some- 
times contradicting) stakeholder requirements. Stakeholders in this context include 
the patients themselves as well as health care professionals and, for example, man- 
agement staff in health care facilities and governmental bodies. 

We are convinced that being aware of these life situations, of the stakeholder 
requirements, and of the basic concepts and terms introduced in Chap. 2 is of great 
importance. These two chapters will give you, the reader, a better understanding of 
the following chapters of this book: Chap. 3 on technology perspectives, Chap. 4 on 
management perspectives, and Chap. 5 on quality. These more generic chapters will 
be rounded out by Chap. 6 on specific health information systems for certain life 
situations and health care settings such as, for example, hospital information sys- 
tems and information systems in personal environments. 

After reading this chapter, you should be able to 


e recognize the relevance of health information systems, 

e understand the motivation and objectives of why this book was written, 

e view life situations in the context of health, health care, and health care settings, and 

e explain the various stakeholders’ requirements of health information systems in 
this context. 


1.2 Life Situations 


As mentioned before, health care starts when people are born (even earlier) and 
ends when people pass away. Sometimes, the relative share of health care in our 
lives is small, sometimes it becomes higher. This section provides an overview of 
some typical life situations. 

Health care organization and health-related processes can vary from country to 
country; however, these life situations seem ubiquitous. We focus on life situations 
related to health care. This view may be limited, as life is much more, but it is useful 
for our topic of health information systems. 


1.2.1 Prevention 


The World Health Organization’s constitution defines health as a state of complete 
physical, mental, and social well-being [1]. Living in good health is by no means a 
given; it must be achieved or preserved by respective measures. In health care, many 
of these measures can be subsumed under the term “prevention” or, more precisely, 
primary prevention. In addition to primary prevention (prevention of diseases), the 
terms secondary prevention (early detection and timely treatment of diseases) and 
tertiary prevention (reduction of negative implications of long term, usually chronic 
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diseases) are well established and used. Prevention mostly takes place in our normal 
daily lives, for example, at the locations where we live and work. Tertiary preven- 
tion may also coincide with rehabilitation. 


1.2.2 Wellness 


Wellness is a term related to prevention, as it also focuses on living in good health. 
In the context of wellness, the term “fitness” can also be found. Wellness and fitness 
activities usually take place in our normal daily lives and at the locations where we 
live and work. Sometimes, wellness activities are done at wellness centers (e.g., 
hotels that are specialized in this field). Sometimes, fitness activities are done at 
sports centers and recreational parks. 


1.2.3 Emergencies 


Emergency situations such as acute heart attacks or severe traffic accidents are com- 
pletely different life situations. Persons suffering such emergency situations frequently 
require immediate assistance. As patients, they are usually brought to the emergency 
units of hospitals, where they are diagnosed and treated by health care professionals. 


1.2.4 Acute Diseases 


Persons suffering from acute diseases also step out of their normal daily lives, at 
least to some extent. With respect to these diseases, these persons have become 
patients. Depending on the kind and severity of such an acute disease, patients may, 
among other things, be treated as outpatients in medical offices or as inpatients in 
hospitals. For outpatients, diagnosis and therapy may take place within these offices 
or at the locations where the patients live. If diagnosis and therapy are performed at 
a distance, these activities are usually subsumed under terms “telehealth” and 
“telemedicine.” 


1.2.5 Chronic Diseases 


The life situations of patients suffering from chronic diseases can be more or less 
viewed similarly to those described for patients with acute diseases. In chronic situ- 
ations, long-term treatment and long-term care is needed, and health care monitor- 
ing becomes more important here. If this monitoring is done at a distance, these 
activities are usually also subsumed under the term “telemonitoring.” 


4 1 Introduction 
1.2.6 Care 


Life situations primarily related to care but not necessarily related to treating dis- 
eases are often characterized by physical and mental functional deficits of the 
affected persons that could lead to frailty, for example. These are often, but not 
exclusively, senior citizens at an advanced age. Care may be provided at these per- 
sons’ private homes, at homes for the elderly, at nursing homes, or, for palliative 
care, at hospices. 


1.2.7 Rehabilitation 


In particular after treatment episodes for inpatients, rehabilitation episodes may 
sometimes follow in order to cure or alleviate diseases. As already mentioned, these 
rehabilitation activities can often be subsumed under tertiary prevention. 
Rehabilitation may take place at inpatient units or may be supported by outpatient 
rehabilitation centers. With acute and chronic diseases, this can be done within such 
centers, or perhaps at a distance through telerehabilitation activities. 


1.2.8 Research for Life 


Another life situation must be mentioned here that to some extent differs from the 
ones described above, as it is also of considerable importance for health information 
systems: the life situation of persons in the context of biomedical research. Patients, 
or even healthy persons, may participate in research activities. For example, patients 
may be asked to participate in randomized clinical trials. Or, as another example, 
data on patients may be stored in disease registers to better understand diseases and 
their diagnosis and therapy in order to improve treatment for future patients. 


1.3 Stakeholders’ Requirements 


As mentioned in the introduction, health care is delivered for people by people. Also 
mentioned was that stakeholder in this context refers to the patients themselves, as 
well as health care professionals, the management staff of health care facilities, or 


1.3 Stakeholders’ Requirements 5 


even governments. This section lists some of the essential requirements that impor- 
tant stakeholders have regarding health information systems. 

Being aware of these stakeholders and their requirements of health information 
systems is important for adequately managing health information systems. We will 
list here major stakeholders, either introduced as persons or as bodies. This is not an 
exhaustive list. The requirements listed here for these stakeholders are important 
requirements with respect to health information systems. These lists will highlight 
some important requirements, but by no means all of them. 


1.3.1 Requirements of Patients 


The patients’ objectives are usually to receive good and affordable health care, to be 
informed and empowered regarding all decisions related to health care and, if pos- 
sible, to receive this care without having to change their normal daily lives too 
much, with social participation and dignity as important properties. 

Requirements that patients have of health information systems are, mostly, (1) to 
be informed (e.g., about appointments with their physicians at medical offices, 
about diseases, about possible diagnostic and therapeutic strategies and their risks, 
or about positive or negative aspects of medication), (2) to be able to communicate 
with health care professionals and their facilities (e.g., asking for an appointment, 
asking for advice), and (3) to be able to provide data or to report (e.g., on unex- 
pected events that may be important to know in the context of their diseases), and 
(4) to feel sufficiently informed and involved when decisions about their individual 
health care are being taken. 

Patients also want to be informed about the qualification and reputation of their 
health care professionals and of their health care facilities. When receiving direct 
advice on health care matters, for example, through the internet or via health apps, 
they also want to know about the quality of the care. 

Regardless of the persons and facilities providing the care, patients expect all 
caregivers to have access to all necessary data in their health record (provided the 
patients give their permission). They also expect data privacy and data confidential- 
ity to be safeguarded. 

Finally, patients expect health information systems to support not only them- 
selves but—perhaps even more importantly—to also support their health care pro- 
fessionals and sometimes their informal caregivers and that this support is 
comprehensive, trustful, and lean. 
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Fig. 1.1 Health information systems constitute an essential part of providing good health care. 
Decisions are made during a ward round in pediatric intensive care. (Courtesy of Karin 
Kaiser/MHH) 


1.3.2 Requirements of Health care Professionals 


Health care professionals usually are physicians and nurses but may also be phar- 
macists, physiotherapists, and midwives, just to mention a few. Their objective is to 
provide good health care for their patients. 

Requirements that health care professionals have of health information systems 
include that these systems support them in doing their work efficiently and in good 
quality. This often involves providing easy and comprehensive access to informa- 
tion in order to make good decisions, with organizational support and with reduced 
documentation efforts while maintaining good documentation quality (Fig. 1.1). 

Having access to all the patient data relevant for adequate diagnostic and thera- 
peutic decisions, for example, is of great importance. If relevant data are missing or 
if data are difficult and time-consuming to obtain, this would risk reducing the qual- 
ity of care and could increase costs. 

Additional requirements include being able to efficiently record and communi- 
cate decisions at the time and place where they were made, receiving decision sup- 
port, and having access to knowledge on diseases and on how to treat them. 
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1.3.3 Requirements of Informal Caregivers 


Informal caregivers are often spouses or close relatives of the patients. Although 
they are usually not trained health care professionals, their contribution to caring for 
patients can be of enormous importance for the quality of health care. 

Requirements that informal caregivers have of health information systems pri- 
marily include being informed of the treatment provided by health care profes- 
sionals, having access to the patients’ health records (provided the patients give 
their permission), having the opportunity to communicate with health care pro- 
fessionals, and recording observations. 


1.3.4 Requirements of Researchers in Biomedicine 


Many researchers in biomedicine need patient data for their research. Provided that 
patients give their permission or that this is allowed by law, the researchers’ objec- 
tive is to access and use these data for their research. This can be routine data 
recorded during patient care at one or several health care facilities. 

Sometimes these data can be aggregated, anonymized data. Biomedical research 
related to patient data is often conducted as part of studies, for example, clinical 
trials or observational studies, with a study plan, elaborated before collecting data, 
and approved by ethics committees. 

Requirements that researchers in biomedicine have of health information sys- 
tems include being supported in doing their work efficiently and in good quality, for 
example, to be able to access, store, and analyze such data with reasonable effort 
and with the potential of attaining good outcomes for medical progress. 


1.3.5 Requirements of Management Staff 


Persons involved in managing health care facilities have certain responsibilities 
related to running their facilities efficiently and in good quality with regard to their 
facilities’ objective of providing health care. For this purpose, these persons must 
document procedures for reimbursement and to ensure the availability of data for 
controlling, this with respect to the sometimes-various levels of health care 
management. 

Requirements that management staff have of health information systems include 
being supported in doing their work efficiently and in good quality. This often 
involves having timely access to controlling data and being able to efficiently use 
analytics tools in the context of data warehousing. 
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1.3.6 Requirements of Insurance Companies 


At this point, we will shift our view from persons to facilities. Health care insurance 
companies want to spend the money obtained from their members to provide these 
members with good and efficient health care when needed. This can involve provid- 
ing timely payment to health care facilities and controlling whether payments have 
been adequate. This may also comprise informing their members on health care 
matters and exploring and promoting new, improved health care processes. 

Requirements that insurance companies have of health information systems 
include being able to carry out these tasks efficiently and in good quality. Insurance 
companies want to be able to verify whether payments that were made were actually 
used for “their” members and that these members were actually insured at the time 
of treatment. 


1.3.7 Requirements of Governmental Bodies 


Governmental bodies with tasks related to health care often involve ministries or 
departments of health. The objectives of such governmental bodies are to provide a 
legal framework for the health care of the people living in a certain state or region. 
Sometimes, they are involved in the practice of health care themselves. 
Requirements that governmental bodies have of health information systems are 
that these information systems support good health care for the people of their state 
or region with reasonable costs and that the information systems provide data and key 
performance indicators (KPI) about the health status of people in the region or nation. 


1.3.8 Requirements of Sponsors 


Health care, health care facilities, and the people providing health care need to be 
financed. Financers of health care and of health care facilities will here be called 
sponsors. Sponsors may be states using taxes paid by their citizens or insurance 
companies using the premiums paid by their members. Sponsors (private compa- 
nies, cities, states, etc.) can also own health care facilities such as hospitals. 
Sponsors usually expect their facilities or services to efficiently provide 
health care that is competitive to facilities delivering related health care and 
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which is financially sound. For non-profit sponsors, this can mean running a 
health care facility without financial deficits. For commercially oriented spon- 
sors, this can mean that health care facilities should work with a profit for the 
sponsors’ stakeholders. 

Requirements that sponsors have of health information systems are that these 
information systems support the objectives mentioned above for the respective 
health care facilities and that they provide the data needed for controlling invest- 
ment costs and running expenses. 


1.3.9 Requirements of Vendors 


Vendors in this context are companies that offer hardware and software or consult- 
ing services for information systems of health care facilities. Vendors may also offer 
tools or services (on prevention and wellness) directly for healthy persons as well as 
for patients and their informal caregivers (e.g., through the internet and via health 
apps) and their settings. 

The objective of vendors is to sell such tools or services and to be competitive 
within their respective markets. In addition to providing good products and services, 
customer retention can also play an important role. 

Here requirements of health information systems are rather indirect, as vendors 
are not users of such systems themselves. 


1.3.10 Requirements of Housing Companies 


In the new era of digitization, the personal home environment can also play a sig- 
nificant role in supporting health care. This is particularly true for persons living at 
home who receive health care as outpatients, for example, with chronic diseases or 
as senior citizens with age-related deficits. Housing companies offering the oppor- 
tunity to use sensor and actor infrastructures within the homes for health care pur- 
poses could be more competitive in their market. 

Requirements that housing companies have of health information systems are 
that these information systems support the objectives mentioned above for the 
respective health care facilities and that they provide opportunities to receive and 
send data from and to health care facilities and to residents’ apps. 
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1.3.11 Coinciding and Contradicting Requirements 
between Stakeholders 


The requirements of the different stakeholders are sometimes similar and therefore 
coincide. Other times, however, they tend to conflict and may even become contra- 
dictory. Being well-aware that requirements of different stakeholders may some- 
times vary and may even contradict is helpful when managing health information 
systems. 

The patient-centered objectives on care of governmental bodies, for example, 
may to some extent contradict the institution-centered objectives of health care 
facilities and their professionals working in health care and management. The 
objectives of health care professionals within a health care facility will tend to focus 
on providing the best health care possible, while managers at the same facility will 
have a focus on cost efficiency and obtaining well-documented data for reimburse- 
ment and controlling. Sometimes, these contradicting requirements may even exist 
within the same person, for example, within a family physician at a small medical 
office who is responsible for both health care and management. 


1.4 Example 


The following example will be used in many parts of this book. Although the situa- 
tions described here are realistic, all persons in this example are fictitious and do 
not exist. 

The Russos live in a flat in a small town on the edge of the commuter belt of a 
large city. Mrs. Russo, a former optometrist, is 68 years old and—following a fall in 
the bathroom last year with a fracture of a leg and some complications—suffers 
from lasting limitations of her movement capacity, affecting her ability to perform 
some of her activities of daily living (e.g., taking a shower, shopping, meeting with 
friends). She was also diagnosed with a mild case of depression along with an anxi- 
ety disorder. Mr. Russo, a former software consultant, is 72 and, following a myo- 
cardial infarction 15 years ago, was diagnosed with heart failure 3 years ago. The 
Russos’ general practitioner (GP), Dr. Andersson, has furthermore diagnosed him 
with hypercholesterolemia (elevated blood cholesterol) and diabetes and has put 
him on medication with several drugs. Dr. Andersson also advised Mr. Russo to take 
up mild physical activity and lose some of his excess weight, but—following a brief 
episode of motivation and a Nordic walking course—he has found it impossible to 
follow her advice and sustain regular physical activity, in part because he increas- 
ingly needs to help his wife in performing her daily activities. 
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One morning, Mr. Russo wakes up early in the morning from severe shortness 
of breath. Although he has experienced this symptom before in a milder form, he 
immediately senses that something is wrong and calls his GP. Dr. Andersson 
comes for a home visit and finds him in bed with low blood pressure, elevated 
heart rate, and pulmonary edema. She diagnoses him with an exacerbation of heart 
failure, strongly advises him to be admitted to Ploetzberg Hospital university med- 
ical center, and subsequently calls an ambulance. The paramedics arrive and per- 
form a resting 12-lead electrocardiogram (ECG), and the emergency physician 
puts Mr. Russo on oxygen. After arrival at Ploetzberg Hospital, Mr. Russo is 
admitted to the cardiology ward and treated with drugs. Blood samples are taken 
and an echocardiography is performed. His condition improves over a week, but 
an intracardiac catheter examination (coronary angiography) shows a severe ste- 
nosis of a main coronary artery, which is treated immediately. Two weeks later, 
Mr. Russo is discharged from the hospital and, following a brief stay at home, 
begins rehabilitation at the Kreikebohm Rehabilitation Centre. Meanwhile, Mrs. 
Russo’s children have organized a home nursing service for her that comes twice 
a day to support her while her husband is away, along with a domestic help to 
assist her with the housework. 

Dr. Andersson receives discharge letters from both Ploetzberg Hospital as 
well as the Kreikebohm Rehabilitation Centre. She adapts his medication 
according to the cardiologists’ advice. Along with his wife, Mr. Russo enrolls in 
a support program arranged by his health insurance company where he uses an 
app on his mobile phone to enter data on his physical and mental well-being and 
his weight. Furthermore, he receives an activity tracker that also measures his 
heart rate. Among other things, Dr. Andersson uses this data to manage the 
course of his disease and for adapting her treatment. Researchers from Ploetzberg 
Hospital ask Mr. Russo whether he would participate in a scientific study to 
investigate the effect of close-knit home monitoring on rehospitalization in 
patients with heart failure, to which he agrees. He can observe his monitoring 
data on his smartphone. 
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1.5.1 Life Situations 


Consider a recent health-related situation you were involved in. Which life situation 
(Sect. 1.2) does it correspond to and what was your role in this life situation (Sect. 
1.3)? List some of the requirements you had in this role and in this life situation. 
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1.5.2 Requirements of Various Stakeholders 


Consider the requirements of various stakeholders when it comes to health informa- 
tion systems supporting various life situations. Can you imagine situations where 
the requirements of two stakeholder groups differ or even contradict each other? 
What does this imply when building health information systems? 
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Chapter 2 A 
Basic Concepts and Terms gree 


2.1 Introduction 


Health informatics specialists usually deal with ambiguous terms based in computer 
science, medicine, health sciences, business informatics, and related disciplines. In 
practice, ambiguous terms lead to difficulties and errors in communication. 

One major objective of this textbook is to provide the reader with a clear termi- 
nology, i.e., a system of concepts and related terms, for health information systems 
and their management. Such a terminology helps health informatics students, prac- 
titioners, and scientists in specifying, describing, and communicating their objec- 
tives, tasks, and working results (Fig. 2.1). 

This chapter introduces the terminology for health information systems and their 
management as used in this book. For describing information system architectures 
for health, we introduce the three-layer graph-based metamodel. It links the logical 
and physical tools that are used in health information systems to health care func- 
tions, which describe the tasks to be performed in certain health care settings, for 
example, patient admission or execution of diagnostic procedures in a hospital. 

To support the learning of the terminology provided in this textbook, some of the 
authors have developed an ontology called SNIK (semantic network of information 
management in hospitals) that contains the most important concepts and terms of 
this book together with their relations to each other.! In addition, the ontology links 
our terminology to other terminologies from business informatics and management 
of information systems. This gives the reader a holistic view of the management of 
information systems in health and its overlap with other disciplines. 

After reading this chapter, you should be able to 


e explain the difference between data, information, and knowledge, 
e define (health) information systems and their components, 


‘https://www.snik.eu. 
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Fig. 2.1 Health information systems constitute an essential part of providing good health care. 
Agreeing on concepts and terms is the precondition for professionally managing informa- 
tion systems 


e define management of information systems, and 
e describe and model health information systems with the help of the three-layer 
graph-based metamodel. 


Please note that the terms highlighted in italics are terms from the glossary or 
represent functions or application system types (Sects. 3.3 and 3.4). 


2.2 Data, Information, and Knowledge 


There are several definitions of data, information, and knowledge. In this chapter, 
we introduce pragmatic definitions which help to distinguish the three concepts 
from each other. 

Assume a physician at Ploetzberg Hospital finds a note on her desk that says 
“Russo”, “8.5”, and “++”. These characters and numbers written on the note 
are data. 


Data are characters, discrete numbers, or continuous signals to be pro- 
cessed in information systems. 
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Metadata is data about data. Metadata provides information about one or 
more aspects of data such as the purpose of the data, author and time of cre- 
ation, used standards, or file size. 


Data cannot be interpreted by a person without knowledge about the documenta- 
tion context. To be reinterpretable, there must be an agreement on how data repre- 
sent information. 

After the physician found the note saying “Russo”, “8.5”, and “++”, she meets a 
nurse who tells her that the note documents the fasting blood sugar level of the 
patient Jakub Russo. Now the physician can interpret the note. “Jakub Russo has a 
fasting blood sugar level of 8.5 mmol/L” is health-related information about the 
patient Jakub Russo. 

There is no unique definition of information. Depending on the point of view, the 
definition may deal with a syntactic aspect (the structure), a semantic aspect (the 
meaning), or a pragmatic aspect (the intention or goal of information). We want to 
define information as follows: 


Information is a context-specific fact about entities such as events, things, 
persons, processes, ideas, or concepts. Information is represented by data. 


What does the symbol “++” on the note mean? The physician can interpret this 
data because she has knowledge about blood sugar levels. She knows that fasting 
blood sugar levels below 5.5 mmol/L are normal, from 5.6 to 6.9 mmol/L are an 
indicator for prediabetes, and above 7.0 are an indicator of diabetes. 


Knowledge is general information about concepts in a certain (scientific or 
professional) domain (e.g., knowledge about diseases or therapeutic methods) 
at a certain time. 


Knowledge as general information contrasts with specific information about par- 
ticular individuals of the domain (e.g., information about a patient). This means 
that, due to the physician’s general knowledge about diabetes symptoms, she can 
conclude that Jakub Russo suffers from diabetes, which, in turn, is information 
about Jakub Russo. 

Although a paper note saying “Russo”, “8.5”, and “++”, and its subsequent inter- 
pretation, is not an example of systematic data, information, and knowledge 
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processing in health care, it may be helpful to understand the difference between 
data, information, and knowledge. 

However, in the context of health information systems and beyond, it is some- 
times difficult to distinguish between the processing of data and information. 
Does an application system for patient administration process data or informa- 
tion during patient admission? Do physicians process data or information when 
they make a diagnosis? Throughout this book, we use the terms “data,” “infor- 
mation,” and “knowledge” as precisely as possible and want to emphasize the 
differences between them. Therefore, the reader should be aware that we have 
given careful thought to the use of terms containing “data,” “information,” and 
“knowledge.” 


2.3 Health care Settings 


In accordance with the World Health Organization (WHO) [1], we regard settings as 
places, social contexts, or facilities where people actively use and shape the envi- 
ronment and thus create or solve problems. In these settings, life situations take 
place. Within these life situations, creating and solving problems requires and 
causes complex information processing. 

If people actively use and shape the environment and thus create or solve prob- 
lems in settings related to health care, we call these settings health care settings. 
Cities, villages, private homes, medical offices, hospitals, health care regions, health 
care facilities, and health care networks are all health care settings. And again, solv- 
ing problems related to health care is essentially characterized by intensive informa- 
tion processing. 


2.4 Systems and Subsystems 


Before considering the details of information systems, let us first define the concept 
of a system. 


A system is a set of persons, things, events, and their relationships forming an 
integrated whole. 


We distinguish between natural systems and artificial (human-made) systems. For 
example, the nervous system is a typical natural system, consisting of neurons and 
their relationships. An artificial system is, for example, a hospital, consisting of 
staff, patients, relatives, and their interactions. If a (human-made) system consists of 
both human and technical components, it can be called a socio-technical system. 
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A system can be divided into subsystems that comprise a subset of the compo- 
nents and the relationships between them. For example, the sympathetic nervous 
system is a subsystem of the nervous system. A subsystem of a hospital is, for 
example, a ward with its staff and patients. Subsystems themselves are again 
systems. 

For professionals, however, the term “system” is often not specific enough and 
needs to be refined in order to avoid misunderstandings (“If you don’t know what it 
is, call it a system.”). 


2.5 Information Systems 


Focusing on processing, storing, and providing data, information, and knowledge in 
settings leads to the term “information system.” 


An information system is defined as that socio-technical subsystem of a set- 
ting which comprises all data, information, and knowledge processing as well 
as the associated human or technical actors in their respective data, informa- 
tion, and knowledge processing roles. 


As stated above, if a (human-made) system consists of both human and tech- 
nical components, it can be called a socio-technical system. But what does 
“socio-technical” mean when looking at the information system of a given set- 
ting? “Socio” refers to the people involved in data and information processing 
(e.g., health care professionals, patients, medical or health informaticians), 
whereas “technical” refers to tools such as computers, software, telephones, and 
paper-based patient records. Thus, when considering the information system of a 
setting, the people and tools in this setting are considered only in their role as 
information processors, carrying out specific actions following established rules. 
A physician carrying out medical admissions of patients in a hospital, for exam- 
ple, follows established rules for interviewing and examining the patients and 
documenting their answers in medical documentation and management sys- 
tems (MDMS). 

An information system can be divided into subsystems called sub-information 
systems. For example, the information system of a setting can typically be split into 
two sub-information systems: the part where computer-based tools are used is called 
the computer-based sub-information system; the rest is called the non-computer- 
based sub-information system of the information system. Information systems of 
health care settings may also be divided by organizational structures (e.g., sub- 
information system of surgical departments or sub-information system of depart- 
ments for internal medicine) or by professions (e.g., sub-information system of 
nursing and sub-information system of medical treatment). 
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2.6 Health Information Systems 


Health information systems support health care professionals working in health care 
facilities as well as healthy or sick persons in their different life situations. The life 
situations as introduced in Sect. 1.2 are linked to various health care settings, such 
as health care facilities, where prevention, patient care, or rehabilitation are carried 
out. Such situations are also linked to the personal home environment, where people 
care for their own health or for the health of their relatives and where they solve 
health-related problems. 

Obviously, health care cannot be considered an isolated procedure taking place 
in one health care facility (e.g., one hospital or one medical office). Instead, health 
care is a patient-oriented process encompassing prevention, diagnosis, and therapy 
going beyond the facilities’ boundaries and integrating the home environment. The 
patient-oriented care process thus takes place in networks of different actors. Such 
actors are, for example, hospitals, medical offices of general practitioners (GPs), 
pharmacies, rehabilitation centers, home care organizations, and even health insur- 
ance companies and governmental authorities. We call these networks health care 
networks. Health care networks can also be understood as health care settings. 

With the definition of information systems in mind, a health information system 
can thus be easily defined: 


A health information system (HIS) is the socio-technical subsystem of a 
health-related setting which comprises all data, information, and knowledge 
processing as well as the associated human or technical actors in their respec- 
tive data, information, and knowledge processing roles. 


A health information system that uses computer-based data processing and com- 
munication tools is called a computer-based health information system. Please note 
that health information systems typically comprise both computer-based as well as 
non-computer-based sub-information systems. 

If we refer to the information system of a certain health care facility, such as a 
hospital or a medical office, we can use the more specific terms “hospital informa- 
tion system” or “medical office information system,” respectively. The information 
system of a health care network can be called a transinstitutional health information 
system (tHIS). 

As a consequence of this definition of a health information system, a health care 
setting has a health information system from the beginning of its existence. 
Therefore, the question is not whether a health care setting should be equipped with 
a health information system, but rather how its performance can be enhanced, for 
example, by systematically managing it or by introducing state-of-the-art tools. 

We will describe health information systems in more detail later in this book, 
especially in Chaps. 3 and 6. In Chap. 3, we will discuss general characteristics of 
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health information systems. In Chap. 6, we will discuss special characteristics that 
arise for information systems in specific (health care) settings. 


2.7 Information Logistics in Health Information Systems 


The goal of a health information system is to sufficiently enable patient care, admin- 
istration, and management. For some types of health care facilities, such as univer- 
sity medical centers, health information systems also have to enable research and 
teaching. 

While managing health information systems, legal and other requirements must 
be taken into account. Legal requirements encompass, for example, data protection 
or reimbursement aspects. Other requirements may result from management deci- 
sions, such as building a common EHR in a transinstitutional information system. 

To sufficiently enable patient care, administration, and management, health 
information systems must do the following: 


e It must make information, primarily about patients, available. Current informa- 
tion should be provided on time, at the right location, to authorized staff, and in 
an appropriate and usable form. For this purpose, data must be correctly col- 
lected, stored, processed, and systematically documented in order to ensure that 
correct, pertinent, and up-to-date patient information can be supplied, for 
instance, to physicians or nurses, so that they can make the right decisions. 

e It must make knowledge available, for example, about diseases, side effects, and 
interactions of medications, to support decision-making in diagnostics and therapy. 

e It must make information available about the quality of patient care and the per- 
formance and cost situation within the health care setting. 


We can summarize this under the term information and knowledge logistics. 


Information and knowledge logistics aims at making the right information and 
knowledge available at the right time, at the right place, to the right people, 
and in the right form so that these people can make the right decisions. 


So what is meant by the “right place”? Persons responsible for information and 
knowledge logistics in health information systems must consider various areas of 
health care settings. Health care networks, for example, can consist of 


e hospitals, 

e medical offices, 

e rehabilitation centers, 

e nursing homes or ambulatory nursing organizations, and 
e personal environments, especially patients’ homes. 


20 2 Basic Concepts and Terms 


Who are the “right people” to be provided with the “right information and knowl- 
edge”? Obviously, the most important people in a health care setting are the patients 
and, in a certain respect, their informal caregivers such as spouses or other close 
relatives. The most important groups of people working in health care settings are 
physicians, nurses, midwives, pharmacists, administrative staff, technical staff, 
medical informaticians, or health information management staff and managers. 
Large facilities, such as university medical centers, are managed by a board of 
directors. 

Within each of these stakeholder groups, different needs and demands on the 
health information system may exist, depending on the role, tasks, and responsibili- 
ties (Sect. 1.3). Ward physicians, for example, require different information than 
physicians working in service units or in a medical office. Patients sometimes need 
similar information as physicians but in a different form. 


2.8 Functions, Processes, and Entity Types in Health 
care Settings 


In this book, we want to clearly and unambiguously describe the systems needed to 
ensure information and knowledge logistics. To do this, we need clear concepts to 
describe the information and knowledge to be provided, the situation in which it is 
needed, and the people involved. For this reason, we introduce the concepts of 
entity, entity type, function, process, and role in this section. 

Entities are excerpts of the real or conceivable world. 

Think back to the “Russo example” from Sect. 1.4. After his stay in the hospital, 
Mr. Russo’s GP Dr. Andersson receives discharge letters from both Ploetzberg 
Hospital and the Kreikebohm Rehabilitation Centre. The “patient Mr. Russo” and 
the “discharge letter for Mr. Russo from 2020-08-15” are examples of entities. 


An entity type is the set of virtual or physical entities that have certain proper- 
ties in common (e.g., “discharge letter” or “patient’’). 


Entity types form a “unit of thought” when talking about similar entities. Thus, 
both the discharge letter for Mr. Russo and a discharge letter for another patient, 
Mrs. Smith, belong to the same entity type “discharge letter” and share the same 
properties such as sending date, author, and recipient. 

For the sake of simplicity, we sometimes take entity types as representatives of 
the covered entities and their data. If, during certain information-processing activi- 
ties (e.g., admitting patients), data on entities (e.g., name of patients’ hometown) is 
used and interpreted, we simply say that the entity type “patient” is used during 
administrative admission of a patient. In this sense, the entity type “discharge letter” 
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is updated during medical discharge. We will also simply say “data on entity type 
X” if we mean the data describing entities of entity type X (e.g., “data on entity type 
“patient’” means data on patients). 

An information-processing function is the class of similar activities which update 
or use entity types. Due to their similarity for all patients in a health care facility, the 
above-mentioned information-processing activities administrative admission and 
medical discharge can be considered information-processing functions. 


An information-processing function (short: function) is a directive in a health 
care setting on how to use data on entity types and how to update data on 
entity types. An information-processing function has no definitive begin- 
ning or end. 


Functions are ongoing and continuous. They describe what is to be done, not 
how it is done. Functions describe which data on entity types are used to perform 
the function and which data on entity types are updated by the function. 

Functions are performed by human or technical actors. 

One can also understand functions as tasks of an actor. But not every task of an 
actor is an information- processing function. It is only an information-processing 
function if data on one entity type is used and, after processing this data, the data on 
another or on the same entity type is updated. For example, a clerk who performs 
the function administrative admission in a hospital needs to ensure that the patient’s 
administrative data, i.e., the patient’s name, contact data, insurance data, and per- 
sonal identifiers, are up to date when the patient is admitted to the hospital. The 
entity type representing patients and their administrative patient data is simply 
called “patient.” During patient admission, the clerk may 


e search for (1.e., “use”) the patient’s administrative data among all instances of the 
entity type “patient” in the patient administration system, 

e check (i.e., “use”) the patient’s administrative data which is already available if 
the patient has been treated in the hospital before, 

e change (i.e., “update’’) parts of the patient’s administrative data if, for example, 
the address or the insurance data has changed, and 

e insert (i.e., “update”) new patient administrative data if the patient is admitted to 
the hospital for the first time. 


Thus, we can state that the function patient admission updates and uses the entity 
type “patient.” 

Functions are usually denoted by nouns or gerunds (i.e., words often ending 
with -ing or -ion), for example, care planning or patient admission. 

Functions can be structured into a hierarchy of functions, where a function can 
be described in more detail by refined subfunctions. For example, nursing admis- 
sion can be seen as a subfunction of patient admission. There are different opportu- 
nities of refining functions that are further described in Sect. 2.14. 
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An activity is an instantiation of a function. For example, “the physician admits 
the patient Mr. Russo” is an activity of the function patient admission. In contrast to 
functions, activities have a definite beginning and end. 

To describe how a function is performed may require not only information about 
its subfunctions but also information about their chronological and logical sequence. 
This information is described by business processes. 


Business processes describe the sequence of activities together with the con- 
ditions under which they are performed. 


Business processes are usually denoted by verbs which can be followed by a 
noun (e.g., “admitting a patient,” “planning care,” or “writing a discharge letter”). 

Instances of a business process are composed of the individual activities; hence, 
they also have a definite beginning and end. While functions concentrate on the 
“what,” business processes focus on the “how” of activities. Functions can be con- 
sidered representatives of business processes. For example, there is the function 
patient admission and the business process patient admission in a hospital. The 
function patient admission is specified by the entity types used and the entity types 
updated when a patient is admitted. The corresponding business process describes 
the activities of patient admission in their chronological and logical sequence. 

For both functions and processes, it is necessary to know who is responsible for 
them or who performs them. The concept of a role summarizes all the stakeholder 
groups and groups of people working in health care settings. 


Roles describe the sum of expectations addressed to persons or groups of 
persons. 


Roles can also be regarded as a surrogate for the set of functions to be performed 
by a person or group of persons together with the resulting duties and the rights 
needed to perform the functions. 

Typical roles in health care settings are ward physician, head nurse, project man- 
ager, or chief information officer (CIO). 

The term “information-processing function” presented in this section is related 
to the term enterprise function from business informatics. Enterprise functions 
mainly emphasize the contribution of activities to business goals, whereas func- 
tions, in the meaning presented here, emphasize the information- processing aspects 
of activities. 
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2.9 Application Systems, Services, and Physical Data 
Processing Systems in Health Information Systems 


Whereas functions describe what is done, we now want to look at how information, 
knowledge, and data processing is done. We will thus take a closer look at tools for 
data, information, and knowledge processing, in particular physical data processing 
systems and application components. 

Physical data processing systems ensure the storage, manipulation, and commu- 
nication of data. 

Most people would intuitively call such systems the physically touchable hard- 
ware of an information system or physical tool. Physical data processing systems 
are able to receive, store, forward, or purposefully manipulate data. We denote 
receiving, storing, forwarding, and purposefully manipulating data as data 
processing. 

Physical data processing systems can be human actors (such as the person deliv- 
ering the mail), non-computer-based physical tools (such as forms for nursing docu- 
mentation, paper-based patient records, filing cabinets, or telephones), or computer 
systems (such as terminals, servers, personal computers (PCs), or tablets). Computer 
systems can be physically connected via data wires, leading to physical networks. 


A physical data processing system is a physical entity that is able to receive, 
store, forward, or purposefully manipulate data. 


For the administration of physical data processing systems that are computer 
systems, it can be useful to abstract from single pieces of hardware and instead 
focus on the optimum use of available processing power, storage, or network capac- 
ity. For this reason, the technique of hardware virtualization has found its way into 
data processing centers in recent years. Virtualization software can help simulate the 
behavior of servers, storage, and networks. Virtual servers (or virtual machines), for 
example, simulate the functionalities of physical servers. To install different soft- 
ware products which require different operating systems, virtual servers that run on 
one physical server can be used. By contrast, in a server cluster, different servers 
could alternatively, depending on their capacity, run a certain application system. 
The server cluster, however, can be managed as one (virtual) server. 

Virtualization techniques to simulate computer systems are widely used in pro- 
fessional health care settings. When using the term “physical data processing sys- 
tems” in this book, we include their possible implementation as simulated computer 
systems, i.e., as simulated physical data processing systems such as virtual machines 
or server clusters. 
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A computer system is useless without software. Software can be considered as 
explicit rules for processing the data in a computer system. 

An application software product is an acquired or self-developed piece of soft- 
ware that can be installed on a computer system. 

By installing and customizing an application software product on a computer 
system and customizing it to the users’ needs, application systems (computer-based 
application components) are created. 


An application system is the installation of a certain application software 
product on a certain computer system. It supports certain functions of a health 
care setting or communication between other application systems and can 
store and communicate data on certain entity types. 


Application systems may be described by the functions they support and by the 
features they provide. Features are functionalities offered by the application soft- 
ware product of the application system which directly contribute to the fulfillment 
of one or more functions. The finer the granularity of a function, the greater is the 
probability that the function semantically corresponds to a feature offered by an 
application system. 

We denote features by a short phrase consisting of at least one verb and one noun 
expressing the ability of the application software product. 

For example, the application system patient administration system stands for the 
installed application software product to support the functions patient admission 
and administrative discharge and billing in a hospital. It may offer the features 
“generate a unique patient identification number’ (PIN) and “provide catalog of 
diagnoses” in order to fulfill the functions patient admission and administrative 
discharge and billing. Other typical application systems are the medical documen- 
tation and management system (MDMS), the computerized provider order entry 
(CPOE) system, and the picture archiving and communication system (PACS). 
These and other application systems are discussed in more detail in Sect. 3.4. 
Application systems store data in database systems. Depending on the architecture 
style of a health information system, each of its application systems either has its 
own database system or uses the database system of another application system 
(Sect. 3.5). 

Even in highly computerized health care settings, not every information- 
processing function is supported by an application system. Sometimes, the rules for 
processing data are not implemented as executable application software product but 
as organizational rules or working plans that describe how people use certain physi- 
cal data processing systems. For example, the rules regarding how, by whom, and in 
which context given forms for nursing documentation have to be used in a certain 
hospital may be described verbally as text in a handbook of this hospital. In this 
example, the paper-based forms that are used represent physical data processing 
systems. We call sets of organizational rules for data processing which are 
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implemented by non-computer-based physical tools “non-computer-based applica- 
tion components.” They are often also denoted as paper-based application 
components. 

“Application component” is an abstract concept for both application systems and 
non-computer-based application components. 


An application component is a set of implemented rules which control data 
processing of certain physical data processing systems. It supports certain 
functions of a health care setting or communication between application 
components. 


For those dealing with the management of an information system, it is important 
to have an overview of the information system’s application systems. However, 
users often do not know which application systems they are using. They are merely 
interested in certain features provided on a website or by an app on their smart- 
phone. The actual application system providing these features may even be hidden 
from the users and invoked by another application system. We call these features 
that are provided by one application system for use by another application system 
and which are thus not immediately used by users “services.” Using a service means 
invoking it. 


A service is an encapsulated feature provided by application systems in order 
to be invoked by other application systems. 


Details on the most relevant tools for data, information, and knowledge process- 
ing, i.e., application components, services, and physical data processing systems, in 
health care settings can be found in Sect. 3.4 and the following sections. 


2.10 Electronic Health Records as a Part of Health 
Information Systems 


The most important functions of health care settings are related to prevention, diag- 
nostics, therapy, and rehabilitation. Obviously, data and documents that are relevant 
to medical decision-making both in diagnostics and in therapy need to be collected 
and presented in a record for the patient. 

Until just a few years ago (and in some cases still in the present), many docu- 
ments in the records have been paper-based documents, such as laboratory results or 
discharge summaries. The portion of documents created and stored in computer- 
based application systems has increased, however, in recent years and will continue 
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to increase further. It therefore seems natural to strive for a record that is used and 
updated by application systems and stored in database systems: the electronic health 
record (EHR). 


The electronic health record (EHR) is the collection of a person’s health data 
from different health care settings. It is stored by one or more application 
systems in a transinstitutional health information system (tHIS). 


This means that the EHR for a person might be scattered physically across the 
database systems of multiple (discrete or interconnected) application systems at 
various health care facilities. Each of the database systems will hold and manage a 
partial EHR containing partial patient information or, to be more precise, containing 
data about patient-specific entity types. Each partial EHR is scoped according to the 
person’s stays at the health care settings which will be discussed in Sect. 3.5. 

EHRs provide relevant information about a person whenever and wherever it is 
needed during patient care. Furthermore, EHRs provide information that is relevant 
for administrative functions, such as billing and quality management. 


An electronic patient record (EPR) is the collection of a person’s health data 
from one certain health care facility where the person is or has been a patient. 
They are stored by application systems designated for this purpose by the facility. 


Some years ago, EPRs were the predominant form of electronic records in health 
care. Hence, potentially relevant information about the medical history of a patient 
that was recorded in one facility was missing or had to be recorded again in another 
facility. This led to quality and efficiency problems. 

Although this situation can still be found in many facilities, efforts are being 
made today to organize EPRs as patient-centric, i.e., independent of boundaries of 
facilities, which will transform the multiple EPRs to one EHR for one person. 

Different strategies can be found to achieve the vision of a complete and lifetime- 
spanning EHR that supports health care on the one hand but respects legal and ethi- 
cal issues on the other. These are described further in Chap. 3. 

In the international literature, the terms EHR and EPR are usually defined as 
presented here. In some countries, however, the use of these terms may differ. 
According to the German data privacy law, for example, health insurers are obliged 
to provide their insured persons with the so-called electronic patient record (EPR) 
which contains selected patient data from different facilities. This “EPR,” in fact, 
corresponds more to our definition of an “EHR.” 
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2.11 Architecture and Infrastructure of Health 
Information Systems 


The architecture of an information system describes its fundamental 
organization, represented by its components, their relationships to each 
other and to the environment, and by the principles guiding its design and 
evolution [2]. 


The architecture of an information system can be described by functions, busi- 
ness processes, application components, services and physical data processing sys- 
tems, and their mutual relationships. 

There may be several architectural views of an information system, e.g., a func- 
tional view looking primarily at the functions or a process view looking primarily at 
the business processes. Architectures that are equivalent with regard to certain char- 
acteristics can be summarized in a certain architectural style. 

The set of components of the information system and services, which are cen- 
trally coordinated and provided for use throughout the health care setting, is 
called the infrastructure of an information system. The infrastructure of an infor- 
mation system consists of physical data processing systems such as servers set up 
centrally in a data center as well as printers and scanners made available for all 
users at central locations. The infrastructure may also contain logical tools such 
as central application systems that have to be used by most of the users through- 
out the health care setting. Moreover, the service desk providing support for all 
users in the health care setting is also part of the infrastructure. Components and 
services that are dedicated only to a specific department are not considered to be 
part of the infrastructure [3]. 


2.12 Management of Information Systems 


Information systems need systematic management. In general, management com- 
prises all leadership activities that determine the goals, structures, and behaviors of 
a setting. Management as a task includes planning, directing, and monitoring a 
specific object. Within a setting, management can focus on different aspects and 
objects of the setting. In companies, for example, a distinction is made between 
management of finances and management of personnel. Accordingly, there is the 
management of a setting’s information system. 
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Management of information systems (short: information management) means 


e planning the information system and its architecture, 

e directing its construction and the further development of its architecture 
and its operation on the basis of these plans, and 

e monitoring compliance of its development and operation with the plan 
specifications. 


The goal of managing information systems is systematic information processing 
that supports information and knowledge logistics and therefore contributes to the 
setting’s strategic goals (such as efficient patient care and high satisfaction of 
patients and staff in a health care setting). Management of information systems 
therefore directly contributes to the setting’s success and the ability to compete. 

Management of information systems encompasses the management of all com- 
ponents of the information system—the management of functions, processes, and 
entity types, of application components and services, and of physical data process- 
ing systems. 

Management of information systems is discussed in detail in Chap. 4. 


2.13 Modeling Information Systems 


Modeling health information systems is an important precondition for their man- 
agement: What we cannot describe, we usually cannot manage adequately. But what 
is a model? 


A model is a description of what the modeler believes to be relevant about 
a system. 


In the sciences, models commonly represent simplified depictions of reality or 
excerpts of it. Models are adapted to answer certain questions or to solve certain 
tasks. Models should be appropriate for the respective questions or tasks. This 
means that a model is only “good” when it is able to answer such a question or solve 
such a task. For example, a model that only comprises the patients (and not the 
nurses) of a ward cannot be used for nurse staffing and shift planning. Since we are 
dealing with management of information systems, this means that models should 
present a simplified but appropriate view of a health information system in order to 
support management of information systems. 

Examples of respective questions that can be answered by specific information 
system models could be: 
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e Which functions are supported by computer-based logical and physical tools? 

e Which tools for data, information, and knowledge processing are used in a nurs- 
ing home? 

e What information is needed if a patient is to be admitted to a rehabilitation hos- 
pital? What information can be provided afterwards? 

e Which functions of a hospital are affected in the event that a specific server 
breaks down? 

e How can the quality of information processing in a regional health care network 
be judged? 


The better a model assists its users in answering a given question, the better the 
model is. Thus, the selection of the adequate model depends on the problems or 
questions to be answered or solved. 

There exists a large number of different classes of models. Each class of models 
is determined by a certain metamodel. A metamodel can be understood as a lan- 
guage for constructing models of a certain class and a guideline for using the 
language. 


A metamodel is a modeling framework which consists of 


e modeling syntax and semantics (the available modeling concepts together 
with their meaning), i.e., the modeling language; 

e the representation of the concepts (how the concepts are represented in a 
concrete model, for example, in a graphical way); and 

e (sometimes) the modeling rules (e.g., the modeling steps), i.e., the guide- 
line for applying the language. 


Just as there are different views on health information systems, there also exist 
various metamodels. Typical types of metamodels are as follows: 


1. Functional metamodels focus on functions (Sect. 2.8) that are supported in a 
health information system. They provide the means to describe dependencies 
between functions, for example, hierarchies of functions or information flows 
between them. 

2. Technical metamodels are used to build models describing the tools for data, 
information, and knowledge processing (see, for example, application compo- 
nents, physical data processing systems, Sect. 2.9) used in a health care setting. 
They also help to describe data transmission or communication links between the 
tools. If the model comprises a graphical presentation of tools and their links, it 
also visualizes the architecture of a health information system. Examples of tech- 
nical metamodels are technical network diagrams or application landscape 
diagrams. 

3. Organizational metamodels help to describe the organizational structure of a 
health care setting. Organizational models typically consist of organizational 
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units or roles and their hierarchies. Examples of organizational metamodels are 
organizational charts (also called organigrams). 


. Data and information metamodels are used for building models of the structure 


of data and information processed and stored inside health information systems. 
Their concepts are typically entity types and their relationships. Examples of 
data metamodels are UML class diagrams (UML = Unified Modeling Language) 
or entity-relationship models (ERMs). 


. Business process metamodels focus on a dynamic view of information process- 


ing in health care settings. They provide concepts that describe the activities to 
be done, their chronological and logical order, the conditions under which they 
are performed, and often their links to roles, organizational units, entity types, 
and logical or physical tools for data and information processing. Examples of 
business process metamodels comprise UML activity diagrams, event-driven 
process chains (EPCs), Petri nets, or the business process modeling and notation 
(BPMN) language. 


. Information system metamodels (also: enterprise metamodels) combine differ- 


ent metamodels (i.e., functional, technical, organizational, data, or business 
process models) into an integrated, enterprise-wide view on information pro- 
cessing in a facility. Examples of information system metamodels comprise the 
three-layer graph-based metamodel (3LGM?, Sect. 2.13), The Open Group 
Architecture Framework (TOGAF), the Extended Enterprise Modeling 
Language (EEML), or the Architecture of Integrated Information 
Systems (ARIS). 


Modeling of health information systems is based on the right selection of a 


metamodel. For health information system modeling, you should therefore consider 
the following steps: 
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. Define the questions or tasks to be solved by the health information system model. 
. Select an adequate metamodel. 

. Gather the information needed for modeling. 

. Create and validate the model. 

. Analyze and interpret the model (answer your questions). 

. Evaluate if the right metamodel was chosen, i.e., if the model was adequate to 


answer the questions. If not, return to step 2. 


Especially step 3 of gathering the information needed for modeling is often time- 
and cost-intensive. 


Modeling patterns which can be customized to the specific situation to be mod- 


eled can reduce the modeling effort. We call these types of models reference mod- 
els. According to the metamodel used, a reference model supports the construction 
of models of a certain class of systems and helps to deal with a certain class of 
questions or tasks concerning these systems. 
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A model is called a reference model for a certain class of systems and a certain 
class of questions or tasks dealing with these systems if it provides model pat- 
terns supporting 


e the derivation of more specific models through modifications, limitations, 
or completions (generic reference models) or 

e direct comparison of different models with the reference model concerning 
certain quality aspects of the modeled systems (e.g., completeness, styles 
of system’s architecture) (non-generic reference models). 


A specific model may be considered a variant of a generic reference model 
developed through specialization (modifications, limitations, or completions). This 
variant is an instance of the metamodel that also underlies the corresponding refer- 
ence model. For example, a model of the processes in a hospital information system 
of a specific hospital may be derived from a general reference model on health 
information system processes. Both the specific model and the reference model 
used are instances of the same business process metamodel. 

A reference model should be followed by a description of its usage, for example, 
how specific models can be derived from the reference model or how it can be used 
for the purpose of comparison. 

Specific models can be compared with a reference model, and consequently 
models can also be compared with each other, judging their similarity or difference 
when describing certain aspects. 

Reference models can be normative in the sense that they are broadly accepted 
and have practical relevance. Reference models are more likely to be accepted if 
they are not only reliable and well-tested but also recommended by a respected 
institution. For example, the initiative Integrating the Health care Enterprise (IHE) 
(Sect. 3.7.2.5) provides a comprehensive set of models describing how to use com- 
munication standards such as Health Level 7 (HL7) and Digital Imaging and 
Communications in Medicine (DICOM) in typical health care settings. These mod- 
els can be regarded as reference models. Many experts in the field use these refer- 
ence models as norms or standards although they are explicitly not. These models 
apparently became normative because they are widely used especially in commer- 
cial invitations of tenders for software supporting radiology departments. 

In the following section, we introduce the 3LGM? as an information system 
metamodel that integrates aspects of functional metamodels, technical metamodels, 
organizational metamodels, and data metamodels. For 3LGM?, there are also refer- 
ence models describing certain aspects of health information systems available 
(Sect. 3.11.1). 
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2.14 3LGM?: A Metamodel for Information 
System Architectures 


The three-layer graph-based metamodel (3LGM?) is a metamodel for modeling 
(health) information systems. It aims to support the systematic management of 
health information systems and especially the structural quality assessment of infor- 
mation processing in health care settings. We will use this metamodel further on in 
this book (especially in Chaps. 3 and 6) and thus present it in detail here. 

Typical questions to be answered with models derived from the 3LGM? 
metamodel are as follows: 


e Which functions of a health care setting are supported? 

e Which information is needed or updated when performing a function? 

e Which application components are used and how do they communicate? 

e Which physical data processing systems are used? 

e Which functions are supported by which application component? 

e Which application components are installed on which physical data processing 
systems? 

e What is the overall architecture of the health information system? 


3LGM? combines functional, technical, and organizational aspects with certain 
aspects of data and process metamodels. As the name indicates, the 3LGM? distin- 
guishes three layers of information systems: 


e domain layer, 
e logical tool layer, 
e physical tool layer. 


The following sections provide a user-oriented description of the three layers, 
complemented by examples from health information systems. 


2.14.1 Domain Layer 


The domain layer of a 3LGM? model describes what kinds of activities in a health 
care setting are enabled by its information system and what kind of data is stored 
and processed. This layer is independent of the implemented physical and logical 
tools for data and information processing. 

Information-processing activities at a certain time and place in an information 
system use certain data in order to create, update, or delete other data. For example, 
the clerk entering Mr. Russo’s administrative data into the patient administration 
system when he arrives at the Kreikebohm Rehabilitation Centre creates or updates 
Mr. Russo’s patient data. For the sake of simplicity, we will from here on subsume 
creating, updating, or deleting patient data under the term “updating.” 
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In Sect. 2.8, we already introduced the important concepts for the domain layer, 
namely entities, entity types, and information-processing functions. Entities are 
excerpts of the real or conceivable world, such as “patient Mr. Russo,” while an 
entity type (such as “patient’’) is a set of virtual or physical entities that have certain 
properties in common. An information-processing function (short: function) is a 
directive in a health care setting on how to use data on entity types and how to 
update data on entity types (such as care planning or patient admission). At the 
domain layer, we now use these concepts for health information system modeling to 
describe entity types, functions, and the relationships between functions and entity 
types performed in a health care setting. 

Figure 2.2 shows an example. The function administrative admission updates the 
entity type “patient,” which represents a patient’s administrative data. This indicates 
that during the administrative admission, patient data such as name, birthdate, 
insurance data, and identification numbers are documented for the first time or 
updated. The entity type “patient” is used by the function medical admission which 
indicates that during a medical admission, the administrative data is available and 
can be used. Medical admission, in turn, updates the patient’s “medical history.” 
This indicates that information on the medical history is documented or updated 
during medical admission. Both the entity types “patient” and “medical history” are 
needed to create a medical care plan. Therefore, these two entity types are used by 
the function medical care planning. In 3LGM? models, functions are represented by 
rectangles and entity types are represented by ovals. 

Functions and entity types can be structured hierarchically by “specialization” 
and “decomposition.” When a function or an entity type is specialized, all its sub- 
elements are a refinement of the function or the entity type and independent of the 
respective super-element. For a function, this means that the activities regarding this 
function are performed differently in different contexts. The function “execution of 
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Fig. 2.2 3LGM” representation of functions (represented by rectangles) and entity types (repre- 
sented by ovals) at the domain layer of 3LGM”. An arrow pointing from a function to an entity 
type represents an updating access of an entity type. An arrow pointing from an entity type to a 
function represents a using access of an entity type 
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diagnostic procedures,” for example, has different specializations in different diag- 
nostic departments. Similarly, an entity type can have different forms for slightly 
different purposes: A radiologic finding is different from a laboratory finding; but 
both are specializations of findings, which is the generalized term (Fig. 2.3). 

By contrast, when a function or an entity type is decomposed, all its sub- 
elements form a proper subset of the function or the entity type. An activity regard- 
ing a function is only completed if all activities regarding all its decomposed 
subfunctions are completed. For example, the activities regarding patient admis- 
sion are only completed if appointment scheduling, patient identification, admin- 
istrative admission, medical admission, nursing admission, and visitor and 
information services have been performed (Fig. 2.4). Similarly, a decomposed 
entity type is only complete when all its subordinate entity types are available. The 
entity type “patient,” for example, must contain a name, a PIN, the patient’s 
address, and insurance data. 

Both decomposition and specialization are represented by dashed arrows from 
sub-elements to super-elements in 3LGM?. For modelers, it is important to differen- 
tiate between specialization and composition at the domain layer. To avoid misun- 
derstandings, it might be useful to predefine the use of only one hierarchical 
relationship for functions or entity types in one model. If this is not possible, one 
should at least consider that an entity type or a function cannot be specialized and 
decomposed at the same time. 

Using relationships and updating relationships between functions and entity 
types are inherited to their sub-elements, no matter whether the functions or entity 
types were decomposed or specialized. This means, for example, that the PIN, 
which is a sub-element of the entity type “patient,” may be updated by the functions 
patient identification, administrative admission, etc. although the “update” relation- 
ship is only modeled between the super-ordinated entity type “patient” and the 
respective functions. 
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Fig. 2.4 3LGM? representation of a decompositions of the function patient admission and of the 
entity type “patient” 


Functions are usually performed in certain parts of health care settings. The exe- 
cution of radiologic procedures, for example, is performed in the radiology depart- 
ment of a hospital. We call those parts of health care settings “organizational units.” 


An organizational unit is a part of a facility which can be defined by 
responsibilities. 


Organizational units such as a radiology department can be decomposed, but not 
specialized. 

Functions, entity types and organizational units are part of a static view of a 
health care setting. For modeling the dynamic view of health care settings, business 
process models are more appropriate. Which entity types and which functions of an 
information system are modeled depends on the health care setting and on the mod- 
eling purpose. Reference models may offer recommendations on important entity 
types and functions for certain kinds of hospitals. 


2.14.2 Logical Tool Layer 
2.14.2.1 Application Systems 
At the logical tool layer, application systems or, in a broader sense, application 


components are the center of interest. As defined in Sect. 2.9, an application system 
is the installation of a certain application software product on a certain computer 
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system. Application components as a more general concept are sets of implemented 
rules that control data processing of certain physical data processing systems. 
Application systems as well as non-computer-based application components sup- 
port functions. 

An application system cannot be bought in a shop but must be constructed by 
customizing a buyable application software product onsite. A patient administra- 
tion system, for example, is implemented by an application software product offer- 
ing features for appointment scheduling, patient identification, checking for 
readmitted patients, and administrative admission. Many application software 
products developed for health care facilities consist of different modules, and buy- 
ers can decide which of the modules of the application software product they pur- 
chase. Application software products for enterprise resource planning systems 
(ERPS), for example, may offer modules for human resource management, mate- 
rial management, financial accounting, and customer or patient administration 
(Fig. 2.5). 

Non-computer-based application components are controlled by rules which we 
can understand as working plans describing how people use non-computer-based 
data processing systems to support a given function. A working plan may be avail- 
able in written form in a document (e.g., in an SOP—standardized operating proce- 
dure). In most cases, however, working plans are verbal agreements or are merely 
specified implicitly. A non-computer-based application component for patient data 
privacy forms, for example, may be controlled by a working plan that describes 
when and how to hand out paper-based data privacy forms to the patients and where 
and how to archive the signed document. 

Application components of an information system are objects that are recog- 
nized and used by staff members in a facility. But nevertheless, they are not tangible 
in the same way as physical tools are. We therefore refer to application components 
also as logical tools. Consequently, we call the layer describing the application 
components the logical tool layer. This is in contrast to the tangible tools, which we 
refer to as physical. 
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Fig. 2.5 3LGM? representation of the application system enterprise resource planning system 
which consists of four sub-application systems and a database system and of the paper-based 
“patient data privacy form system” as non-computer-based application component 
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At the logical tool layer, application components are responsible for supporting 
functions and for storing and communicating data on certain entity types. Computer- 
based application components usually store data in database systems which are 
controlled by database management systems. Non-computer-based application 
components use document collections for data storage. 

Both application systems as well as non-computer-based application compo- 
nents are represented by rounded rectangles at the logical tool layer of a 3LGM? 
model. Visually they can be distinguished by different coloring and the different 
symbols for database systems (cylinders) and data collections (dashed rectangles, 
Fig. 2.5). 

For communication between two application systems, we distinguish between 
the message-oriented and the service-oriented communication paradigm, which are 
explained in the following sections. 


2.14.2.2 Message-Oriented Communication 


For message-oriented communication, application systems use communication 
interfaces. A communication interface can either send or receive messages over 
communication links. A patient administration system, for example, may communi- 
cate with an MDMS by sending messages over communication interfaces and a 
communication link (Fig. 2.6). In this example, the message may comprise informa- 
tion on the admission of a patient and the related administrative patient data. 

A message is a set of data on entities (e.g., administrative data on a given patient) 
that are arranged as a unit in order to be communicated between application sys- 
tems. A message type describes a class of uniform messages and determines which 
data on which entity types is communicated by a message belonging to this message 
type. For example, the message type “patient administrative data” could describe 
how the administrative data on a patient (name, address, identification number, 
insurance data, etc.) must be arranged in a uniform way in order to be understood by 
both the patient administration system and the MDMS. 

A message type can belong to a communication standard, i.e., a standard for 
syntactic interoperability (Sect. 3.7.1). There are several communication standards 
which describe how messages of a certain data format must be communicated 
between application systems. In medical informatics, Health Level 7 Version 2 
(HL7 V2) and DICOM are well-known examples of such message-oriented 
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Fig. 2.6 3LGM? representation of a patient administration system’s communication interface 
(represented by a circle) sending messages to a medical documentation and management system’s 
communication interface over a communication link (represented by an arrow) 
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communication standards (Sects. 3.7.2.1 and 3.7.2.4). Application systems have to 
communicate by using their interfaces to ensure that functions can use and update 
entity types as described at the domain layer. 

The concept of a message-oriented communication paradigm may also be used 
to model the communication between application systems and non-computer-based 
application components. 


2.14.2.3 Service-Oriented Communication 


The service-oriented communication paradigm assumes that application systems 
provide encapsulated features (“services”) that can be used by other application 
systems. A patient administration system, for example, could offer a service 
“get patient” to other application systems within a health care facility. When invok- 
ing this service, an application system such as the MDMS can request and obtain the 
administrative patient data of a given patient from the patient administration system. 

Application systems need “providing interfaces” to provide services to other 
application systems and “invoking interfaces” to invoke services provided by other 
application systems. In 3LGM? models, invoking interfaces are represented by cir- 
cles and providing interfaces are represented by triangles (Fig. 2.7). 

Services themselves are not graphically represented at the logical tool layer but 
can be assigned to interfaces. Services of a similar type can be summarized in 
3LGM™” service classes. 

A function can be either supported by one service or by a set of combined 
(“orchestrated”) services. In health information systems, the interoperability stan- 
dards HL7 FHIR (Fast Health care Interoperability Resources) and open Electronic 
Health Record (openEHR) support the implementation of service-oriented architec- 
tures (SOA). 

Communication with non-computer-based application components can take dif- 
ferent forms and is therefore considered separately. 

Communication of data between two non-computer-based application compo- 
nents is only possible through an active human intervention, for example, by carry- 
ing a paper document from one place to another. 

In a similar way, human intervention is necessary for the communication between 
non-computer-based application components and application systems. Scanning a 
paper form for archiving or typing a discharge letter which is available as an audio 
recording are examples of communication from a non-computer-based application 
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Fig. 2.7 3LGM” representation of a situation where the patient administration system provides a 
service “get patient” invoked by the medical documentation and management system 
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Fig. 2.8 Communication between an application system and a non-computer-based application 
component 


component to an application system. Printing out a paper form available in the 
MDMS or storing radiological images on a memory device to be taken to another 
health facility by a patient are examples of communication from an application 
system to a non-computer-based application component. Figure 2.8 shows the 
3LGM? representation of such “media breaks” between application systems and 
non-computer-based application components. The details of the communication 
should be modeled by messages (Sect. 2.14.2.2). 


2.14.3 Physical Tool Layer 


The physical tool layer describes physical data processing systems and their data 
transmission links among each other. As defined in Sect. 2.9, a physical data pro- 
cessing system is a physical entity that is able to receive, store, forward, or purpose- 
fully manipulate data. 

For the computer-based part of information systems, servers, PCs, notebooks, 
tablets, switches, routers, smartphones, etc. are modeled at the physical tool layer. 
In addition, virtualized physical data processing systems are modeled at the physi- 
cal tool layer because they behave like physical data processing systems to the out- 
side world (Sect. 2.9). 

For the non-computer-based part of information systems, human actors (such as 
persons delivering mail) and non-computer-based physical tools (such as printed 
forms, telephones, books, paper-based patient records, administrative stickers) are 
modeled at the physical tool layer. 

Figure 2.9 shows a simple model of the physical tool layer. A virtualized server 
farm is represented by one physical data processing system. This “black box” is 
connected to a patient terminal, a PC and a tablet PC. The physician uses both a 
tablet PC and a telephone as physical computer-based or non-computer-based tools, 
respectively. 

Depending on the modeling goals, health professionals, patients, or caregiving 
relatives can be modeled as physical data processing systems (as in Fig. 2.9) to 
highlight their information-processing role in the health information system. In 
most cases, this will not be necessary. 

To specify the relationship between physical data processing systems and virtu- 
alized physical data processing systems in a 3LGM? model, a “‘virtualizes” relation- 
ship can be modeled. Figure 2.10 illustrates the 3LGM? representation of 
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virtualization techniques. In a server cluster, physical data processing systems can 
run certain application systems alternatively. Virtual machines allow multiple oper- 
ating systems or different instances of one operating system to run on one physical 
data processing system (compare Sect. 2.9). 

Physical data processing systems such as a specific server or a specific PC can be 
assigned to a “tool class” (e.g., server, PC) and a location. 

Physical data processing systems are physically connected via data transmission 
links (e.g., communication network, courier service) which can use different trans- 
mitting media. A transmitting medium is either signal-based (e.g., copper cable, 
optical fiber) or non-signal-based (e.g., sheet of paper, CD-ROM, USB flash drive). 

Physical data processing systems can be refined by decomposition. A physi- 
cal data processing system can be part of exactly one physical data processing 
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system. Thus, the lower part in Fig. 2.10 does not show a decomposition but a 
virtualization. 


2.14.4 Inter-layer Relationships 


A variety of dependencies, called inter-layer relationships, exist among concepts of 
the three layers of a 3LGM? model. Relationships exist between concepts of the 
domain layer and the logical tool layer and between concepts of the logical tool 
layer and the physical tool layer. 

The following relationships between the domain layer and the logical tool layer 
can be modeled in 3LGM?: 


e Functions (domain layer) can be supported by application components or, in 
SOA, by services which are both modeled at the logical tool layer. 

e Entity types (domain layer) or, more exactly, their representation by a dataset or 
document collection, can be stored in an application component (logical 
tool layer). 

e An application system storing an entity type can, in addition, be the primary 
application system of that entity type. This means that the application system 
contains the “original” data on that entity type. Data on that entity type that are 
stored in other application systems have to be considered copies of the “original” 
data. Consequently, only data in primary application systems can be updated 
directly by users; data integrity in the other application systems must be main- 
tained by sending new copies of the original data to the other application systems 
(see Sects. 3.5 and 3.8.1 for an in-depth discussion of data integrity and data 
integration). 

e Inthe message-oriented communication paradigm, entity types or, more exactly, 
their representation by a message can be communicated over communication 
interfaces and communication links. 

e In the service-oriented communication paradigm, entity types are represented by 
parameters that are handled by services. 


Between the logical tool layer and the physical tool layer, there are two types of 
relationships expressing that application components need certain physical data 
processing systems to work: 


e One relationship between application components and physical data processing 
systems states that an application component needs physical data processing sys- 
tems to be able to provide its features. For example, an application system needs 
to be installed on a server to make its features available. 

e The second relationship between application components and physical data pro- 
cessing systems states that application components need a physical data process- 
ing system to store data on entity types. 
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2.14.5 First Steps of 3LGM? Modeling 
2.14.5.1 Installation of the 3LGM? Tool 


To start modeling, the current version of the full version of the 3LGM? tool can be 
downloaded from http://www.3lgm2.de. The Java-based tool runs on different plat- 
forms and can freely be used for non-commercial purposes. 


2.14.5.2 Modeling the Domain Layer 


The main elements of the domain layer are entity types and functions. When model- 
ing a domain layer from scratch, the following rules should be observed: 


e Each function should use and update at least one entity type. 

e Very similar or even equivalent functions that are performed in different areas, 
different organizational units, or different health care facilities of a health care 
network should be modeled only once at the domain layer. The functions can be 
identified as similar by checking whether they use and update the same set of 
entity types. 

e If an entity type is updated or used by a function that is decomposed or special- 
ized, then all of the subfunctions also use or update the entity type. For clearer 
models, it can be helpful to assign entity types only to functions that are not 
further refined by subfunctions. 

e Functions should be decomposed or specialized only to that level of detail needed 
to describe the support of the functions by single application components. 

e “Documentation” may not be modeled as a function in 3LGM? because it is an 
inherent part of a function updating an entity type. If an entity type is updated by 
a function and this entity type’s data are stored in an application component, we 
call this combination the “documentation of the entity type.” However, some- 
times it may improve the readability of a model to include the word “documenta- 
tion” in a function’s name. 


Identifying appropriate functions and entity types for a specific health care set- 
ting is a non-trivial task. The most elaborate but also the most direct way to identify 
functions and entity types of a setting is to conduct interviews with the persons 
performing the functions. Preparing and conducting these interviews, function pat- 
terns, or reference models providing lists of typical functions and of relationships 
between the functions of a specific type of health care setting may be helpful. In 
Chap. 3, we develop patterns for functions that are performed in many health care 
settings. These patterns as well as a reference model for the domain layer of hospital 
information systems are available at http://www.3lgm2.de and can be used and 
refined for modeling a specific health information system. 
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2.14.5.3 Modeling the Logical Tool Layer 


The logical tool layer describes the application components of a health care setting 
and the communication between these components. For modeling the logical tool 
layer, the following rules should be observed: 


e Application systems are installations of application software products. For every 
installed instance of an application software product, there should be one appli- 
cation system in a 3LGM? model. 

e Application software products in health care often consist of different modules 
for different functional areas (e.g., a module for operation planning and execu- 
tion, a module for nursing). Thus, an application system may consist of sub- 
application systems (modeled by part-of relationships) according to the installed 
modules of an application software product. 

e For message-based communication between two application systems, each 
application system should have at least one communication interface. The mes- 
sage type communicated over a communication link between two communica- 
tion interfaces should be named according to the message type of the 
communication standard used. If the technical name of the message type is not 
known or the message type is proprietary, the name of the message type should 
describe the message type’s content concisely, for example, by using the name of 
the entity type connected to the message. 

e Depending on the modeling scope, the modeler may decide to model only appli- 
cation systems or to model a mix of application systems and non-computer-based 
application components. 

e There are at least two strategies for modeling non-computer-based application 
components. (1) All non-computer-based information processing of the logical 
tool layer of a health care setting can be modeled with the help of one non- 
computer-based application component having several communication links to 
application systems of the setting. (2) For each application system where there is 
an intervention of a person necessary to enter data which are already documented 
at another medium, a non-computer-based application component describing 
this media break is modeled. Likewise, for each application system where inter- 
vention by a person is necessary to transfer data stored in the application system 
to another medium, a non-computer-based application component describing 
this media break is modeled. 


To obtain a correct representation of a logical tool layer, it is in most cases not 
sufficient to interview health care professionals who work within the health infor- 
mation system. They often have too little insight into the technical details of the 
logical tool layer. Interviewing information management staff or analyzing the cur- 
rent documentation of the information system are the most promising methods for 
obtaining information about the logical tool layer of a health care setting. 
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2.14.5.4 Modeling the Physical Tool Layer 


Physical data processing systems and their connections are modeled at the physical 
tool layer. This layer has the fewest modeling rules. Depending on the purpose, the 
modeler must decide whether to model single physical data processing systems 
such as servers and PCs or to provide a more abstract view, for example, by model- 
ing the data processing center of one facility as one physical data processing system. 

Information about the physical data processing systems and the network can be 
obtained from the staff of the information management department or the data pro- 
cessing center, respectively. 


2.14.5.5 Modeling Inter-layer Relationships 


Functions are to be connected with application components supporting them in a 
health information system. To establish this relationship between the domain layer 
and the logical tool layer, the organizational unit where the function is supported by 
the application component should be specified. This is especially important if a 
function is supported by one or more application components in a health care set- 
ting. Therefore, even if one of these application components fails, this function 
could still be performed, at least in selected organizational units. In this case, we 
have a functional redundancy which may be an indication for superfluous applica- 
tion components. 

There are also desired functional redundancies. To update the application soft- 
ware product of an application system, it might be necessary to shut down an appli- 
cation system for a few hours. If this concerns an application system which is 
permanently in use, such as an MDMS, it can be helpful to have an evasive applica- 
tion system. 

However, we must also be careful that supposed functional redundancy does not 
result from inaccurate modeling. 

In a 3LGM? model, we specialize or decompose functions to that level of detail 
needed to describe the support of the functions by single application components. 
That means if we think of the hierarchy of functions in a 3LGM? model as a tree in 
graph theory, then each of the tree’s “leaf functions” must completely be supported 
by one application component of the information system. We only assign applica- 
tion components to the “leaf functions” of the tree. For example, if we find that the 
function medical and nursing care planning needs joint support of two application 
components X and Y, we have to specialize or decompose the function in such a way 
that the resulting subfunctions are supported by X and Y, respectively. If X is used 
by clinicians and Y is used by nurses, a solution could be to decompose the function 
into medical care planning and nursing care planning. 

Besides the relationship between functions and application systems, it is impor- 
tant not to forget to model the relationships between entity types of the domain layer 
and their representation forms at the logical tool layer (message types, parameters, 
dataset types). 
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Between the application systems at the logical tool layer and the physical data 
processing systems at the physical tool layer, the relationships have to be mod- 
eled—both for expressing the installation of an application component on a physi- 
cal data processing systems and for the storage of data in such a system. 


2.15 Example 


For this example, we merge many of the small examples of Sect. 2.14 into one 
3LGM? model showing a section of the information system of a fictional hospital. 
Figure 2.11 illustrates which logical and physical tools are used for the function 
patient admission in the hospital. Four subfunctions of patient admission (appoint- 
ment scheduling, patient identification and checking for readmitted patients, admin- 
istrative admission, and visitor and information services) are supported by the 
patient administration system, which is a part of the ERPS. Medical admission and 
nursing admission are supported by the MDMS. Obtaining consent for processing of 
patient-related data is supported by the non-computer-based application component 
for patient data privacy forms. This application component is based on paper forms 
which are scanned by a clerk (see physical tool layer) and then stored in the MDMS. 

The patient administration system, which is the master application system (Sect. 
3.9.1) for the entity type “patient,” sends the administrative patient data as a mes- 
sage to the MDMS. The MDMS can thus store this information about the entity type 
“patient” in its own database; administrative patient data that is needed to support 
medical admission and nursing admission as functions therefore do not have to be 
reentered in the MDMS. The entity type “patient” is both stored in the database 
systems of the ERPS and the MDMS what is represented by dashed lines between 
the domain layer and the logical tool layer in Fig. 2.11. 

Both the patient administration system and the MDMS are run on servers at a 
virtualized server farm (see relationships between logical and physical tool layer). 
The application systems can be accessed by different end devices (patient terminal, 
PC, tablet PC). 

Note that Fig. 2.11 shows a model of the information system expressing what the 
modeler believed to be relevant about the information system. It therefore simplifies 
some aspects which might be relevant in other contexts. 

Another visualization of relationships between 3LGM? model elements is the 
matrix view. Figure 2.12 shows connected functions (columns) and application 
components (lines) expressing that the functions are supported by certain applica- 
tion components. The patient administration system supports three different func- 
tions, the MDMS supports two functions, and one function is supported by the 
paper-based patient data privacy form system. The matrix view also helps to iden- 
tify incomplete parts of models. In Fig. 2.12, we can see that there are no functions 
modeled that are supported by the financial accounting system, the human resources 
management system, and the material management system, which are parts of 
the ERPS. 
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Fig. 2.11 3LGM? representation of domain layer, logical tool layer, and physical tool layer and 


their relationships of the function patient admission in a hospital 
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Fig. 2.12 The matrix visualizes the relations between functions and application components 


The matrix view presented in Fig. 2.12 is an alternative representation of con- 
figuration lines between functions at the domain layer and application components 
at the logical tool layer (compare Fig. 2.11). Matrix views are also available for 
visualizing relations between other pairs of connected 3LGM? classes. 


2.16 Exercises 


2.16.1 Data, Information, and Knowledge 


Imagine that a physician is given the following information about his patient, Mr. 
Russo: “Diagnosis: hypertension. Last blood pressure measurement: 160/100 
mmHg.” Use this example to discuss the difference between “data,” “information,” 
and “knowledge”! 


2.16.2 Systems and Subsystems 


Look up some information on the nervous system of the human body. Then try to 
identify subsystems of the nervous system. In the same way, can you also describe 
subsystems of the system “hospital”? 
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2.16.3 Information Logistics 


Imagine a situation in which a physician speaks with Mr. Russo at the patient’s 
bedside. The physician looks up Mr. Russo’s recent blood pressure measurement 
and ongoing medication, decides to increase the level of one medication, and 
explains this to Mr. Russo. Use this example to discuss the meaning of “information 
and knowledge logistics.” What in this example indicates the right information, the 
right place, the right people, the right form, and the right decision? What could hap- 
pen if an information system does not support high-quality information and knowl- 
edge logistics? 


2.16.4 3LGM? Metamodel 


Look at the 3LGM” example in Sect. 2.15. Use this example to explain the meaning 
of the following elements: functions, entity types, application systems, non- 
computer-based application components, physical data processing system, and 
inter-layer relationships. 


2.16.5 Interpreting 3LGM? Models 


Look at the 3LGM? sample model in Sect. 2.15 and try to answer the following 
questions. 


(a) Find examples of specialization or decomposition at the domain layer in 
Fig. 2.11. 

(b) What is the meaning of the arrows pointing from patient identification to 
“patient” and from “patient” to medical admission in Fig. 2.11? 

(c) What entity type that is stored in the paper-based patient data privacy form 
system should be added at the domain layer in Fig. 2.11? 

(d) Why is the function patient admission not connected with any application sys- 
tem in Fig. 2.11? (Hint: Look at the graphical representation of the domain 
layer in Fig. 2.11 and remember the modeling rules from Sect. 2.14.5.) 

(e) Which physical data processing systems are needed for the function “obtaining 
patient consent for the processing of data”? 
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Chapter 3 A 
Technological Perspective: Architecture, gede 
Integration, and Standards 


3.1 Introduction 


From the previous chapter, we already know that a health information system is the 
socio-technical subsystem of a health care setting which comprises all data, infor- 
mation, and knowledge processing as well as the associated human and technical 
actors in their respective data, information, and knowledge processing roles. In this 
chapter, we first look at what these information systems look like, i.e., we take the 
technological perspective and examine the architecture of information systems. 
This perspective is then complemented by the management perspective in Chap. 4. 

Section 2.11 taught us that health information systems are constructs built from 
a variety of components. We will go through the three layers of information sys- 
tems: the domain layer, the logical tool layer, and the physical tool layer. For each 
layer, we will explain, step by step, the layer’s components and how they are to be 
assembled and integrated to achieve what users experience as the health information 
system. Although we keep the non-computer-based part in mind, we will focus on 
the computer-based part. 

In Sect. 3.2, we start at the domain layer and discuss the kind of data that must 
be processed in health care settings before, in Sect. 3.3, we present the functions 
interpreting or updating these data. From Sect. 3.4, we describe the tools for data, 
information, and knowledge processing to be used in health care settings. Starting 
at the logical tool layer and its application components, we explain how interoper- 
able application components can be integrated, i.e., connected to work together 
seamlessly (Fig. 3.1) and how various approaches for integration lead to different 
architectural styles. At Sect. 3.10, we start describing tools at the physical tool layer. 
Again, we are dealing with integration. But we must be aware that at the physical 
tool layer, physical data processing systems and the challenges of integration are 
different from those at the logical tool layer. 

In this chapter, we will explain the more generic technological concepts for 
health information systems which, in principle, are valid for most life situations and 
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Fig. 3.1 Health information systems constitute an essential part of providing good health care. 
Decisions are made by an interdisciplinary tumor board. (Courtesy of Karin Kaiser/MHH) 


health care settings. However, in certain situations and settings, there are specific 
challenges and requirements leading to specific architectures for the respective 
health information systems. In Chap. 6, we will therefore discuss how information 
systems for certain life situations and in certain settings actually take up these chal- 
lenges and fulfill these requirements. 

After reading this chapter, you should be able to 


e differentiate the most important entity types which are processed in health care, 

e explain important information-processing functions of health care settings, 

e name and describe types of application systems used in health care settings, 

e explain typical architectural styles of health information systems and describe 
them by differentiating concepts and relationships at the domain layer and the 
logical tool layer, 

e explain the different types of integrity, interoperability, and integration at the 
logical and physical tool layer, 

e select suitable technologies and tools for achieving integration, and 

e describe the available standards for different aspects of interoperability and 
select suitable standards for achieving specific types of integrity, interoperability, 
and integration. 


For you as a reader, achieving these learning objectives is the prerequisite for 
being able to construct health information systems that are appropriate to people’s 
life situations and that meet the stakeholders’ needs. However, you must be aware 
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that these information systems will only be useful to people if they are systemati- 
cally managed from the start and if their quality is systematically monitored. We 
will take a closer look at these aspects later on in Chaps. 4 and 5. 

Please note that the terms highlighted in italics are terms from the glossary or 
represent functions or application system types (Sects. 3.3 and 3.4). 


3.2 Domain Layer: Data to be Processed and Provided 


We will now look at data that represent information and knowledge in both the 
health care sector and biomedical research. We need to be aware that data is not only 
stored and processed in one particular information system, but that it often also 
needs to be provided to or shared with the information system of another facility or 
setting. For example, data from health care should be provided for research so that 
medical progress is possible. And data from research should be provided for use in 
health care to apply new knowledge. This mutual relationship is often described 
with the concept of the “learning health care system,” in which data from everyday 
medical care is used to gain new insights in medical research and the research 
results are constantly fed back into practical care (translation) and medical education. 
We can distinguish data according to different aspects: 


e personal vs. non-personal data, 
e standardized vs. non-standardized data, 
e data on particular entity types (compare Sect. 2.8). 


These distinctions are useful because 


e personal data require special security measures and are subject to certain restric- 
tions on their processing, 

e non-standardized data are more common in the health care sector but much more 
difficult to process and to be used by machines than standardized data, and 

e data on specific entity types require specific application systems and algorithms 
for processing. 


After this section, you will understand what kinds of data are processed in and 
provided by most of the health care settings and in biomedical research. 


3.2.1 Personal vs. Non-personal Data 


According to the European General Data Protection Regulation (GDPR) “... ‘per- 
sonal data’ means any information relating to an identified or identifiable natural 
person” [1]. Data on health and illness are mostly created as personal data. For 
example, a 12-lead electrocardiogram (ECG), data on physical/mental well-being 
and weight, the results of an echocardiography, or the activity data for a particular 
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person like Mr. Russo (Sect. 1.4) are personal data. Individuals’ health data belong 
to the most sensitive personal data on humans. 

By cumulating data, the relation to a single identifiable person can be reduced. 
Whether this really turns personal data into non-personal data, however, depends on 
the information represented. Look, for example, at the German city of Leipzig with 
around 500,000 inhabitants. Data describing that there are 50,000 people with ele- 
vated body temperature in Leipzig in December would certainly not be personal 
data. On the other hand, if there is a certain rare disease occurring only once among 
1,000,000 people, and there is a record with data on a citizen of Leipzig suffering 
from this rare disease, then this is personal data, even if the data do not include a 
name, birthday, or other identifier. This is similarly true for human genetic data. 
Since the genetic code is individual for each person, such data must always be con- 
sidered personal data. 

Personal health data must only be accessible to those persons the individual has 
authorized before. A health information system must guarantee this requirement of 
personal data privacy. Likewise, the health information system must ensure data 
security and data safety of personal health data. While data security ensures avail- 
ability, confidentiality, integrity, and protection from unauthorized access, data 
safety concerns protecting personal data against loss. 

Personal data on certain persons may only be processed by other persons or 
facilities if the person expressly consents to having their data processed. If the data 
are to be processed for another purpose at a later time, the person must give their 
consent again. In medicine, for example, this means that health data collected from 
a patient during treatment at a particular health care facility may only be transferred 
to another health care or research facility with the patient’s consent. Thus, Mr. 
Russo must also first give his explicit and informed consent for his data to be used 
in the scientific study to investigate the effect of close-knit home monitoring on 
rehospitalization in patients with heart failure. This also applies to pseudonymized 
health data, i.e., data in which the directly identifying data on the person, for exam- 
ple, the name or a patient number, have been replaced by a number that cannot be 
directly assigned to a person. 

National legislation may allow for different levels of consent. For example, it 
may be a requirement that individuals must give permission for their data to be used 
individually for each research project. However, it may also be possible for indi- 
viduals to give permission for the use of their data for a broader research topic or for 
research in general (often called “broad consent’). It is important, therefore, to 
know exactly what options are available in your country. 

The handling of personal data in the European Union is comprehensively regu- 
lated by the GDPR [1]. 

Not only personal data but also the processing of non-personal data may be sub- 
ject to restrictions. For example, if the data are research data obtained by a scientist 
in the course of experiments at great expense, then this scientist has intellectual 
property (IP) rights. Such data may only be used if this scientist agrees to its use. 
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3.2.2 Standardized vs. Non-standardized Data 


When a physician, for example Mr. Russo’s cardiologist, documents the medical 
treatment, the data used to describe the treatment, for example in the discharge 
letter, may be recorded as continuous narrative text without further structuring. 
We refer to such free text as non-standardized data. With free text, a situation 
can be described in detail and exactly using full linguistic expressiveness—if 
there is enough time. The disadvantage of such non-standardized data is, how- 
ever, that the recorded data are hardly comparable, their completeness cannot be 
checked, and further processing, especially interpreting its semantics by a 
machine, is very difficult. However, there are promising approaches from artifi- 
cial intelligence to use natural language processing (NLP) to tag free texts with 
terminologies (e.g., Systematized Nomenclature of Medicine Clinical Terms 
(SNOMED CT)) in such a way that further processing is possible. For example, 
the SNOMED CT code 414024009 may be used to tag the discharge letter 
describing Mr. Russo’s coronary artery disorder. The other two problems, how- 
ever, cannot be solved with this approach. 

If, prior to documentation, the entity types for which data are to be recorded, the 
properties (attributes) of the objects of these entity types that are to be documented, 
and the exact value set of these attributes are defined, then we speak of a standard- 
ized documentation or of standardized data (example in Fig. 3.2). In the case of 
standardized documentation, it is easy to see—and to validate by a machine— 
whether all the desired data have been captured and the data from different sources 
can be easily compared. Further processing by machine is also well-prepared. To 
support standardized documentation, certain terminologies exist and can be used. 
Depending on the purpose of the documentation, these may be terminologies such 
as the SNOMED CT mentioned above or classifications such as the International 
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Fig. 3.2 Excerpt from the English version of the Shoulder Pain and Disability Index; a standard- 
ized questionnaire for assessing shoulder function [2] 
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Classification of Diseases (ICD) or the nursing diagnosis classification of the North 
American Nursing Diagnosis Association (NANDA) International. NANDA may 
be used to assign the aforementioned case of Mr. Russo to the class 00146, for 
example, as Mr. Russo still suffers considerable anxiety from his heart problems. 
Thus, cases assigned to certain classes can be counted and statistically analyzed. 

As standardized data, in contrast to free text data, have a certain structure, they 
are often also called structured data. Accordingly, free text is often referred to as 
unstructured data. 


3.2.3 Entity Types 


In health information systems, data on the following entity types are particularly 
important: 


e entity types about individuals, 

e entity types about patients’ diseases and their treatment, 
e entity types about organizing health care, 

e entity types about knowledge. 


In the previous two sections, we saw the difference between personal and non- 
personal data and between standardized and non-standardized data. Please note that 
a lot of data describing individuals are personal data. However, this is not always 
true. For example, diagnoses without reference to a specific person are non-personal. 
There are also differences in terms of standardization for data describing individu- 
als. For example, findings can be standardized or non-standardized. 


3.2.3.1 Entity Types About Individuals 


The following entity types describe individuals. They are listed in alphabetical order. 


Entity type | Description 


Health care Health care professionals are persons who treat, according to their specialization 
professional | (e.g., nephrology or pediatrics), patients with certain leading diagnoses. 
Examples of health care professionals include physicians and nurses 


Human Human resources are persons working in health care facilities, i.e., health care 
resource professionals, nurses, administrative staff members, and IT staff members 
Informal Informal caregivers are persons who are not trained health care professionals 
caregiver but who care for a patient, for example, a relative or close friend 

Patient Patients are persons who are the subject of health care. Information about a 


patient includes the patient identification number (PIN) and—in 
transinstitutional information systems—the transinstitutional PIN 


Person Persons are individuals who are dealt with in a certain health information 

system. This includes individuals who are taking care of their own health in any 
way or who are subjects of health care at a health care facility. Persons may also 
be health care professionals, informal caregivers, or participants in clinical trials 
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In health information systems, it is crucial to be able to identify persons unam- 
biguously in order to avoid mix-ups. Each person must be assigned a unique patient 
identification number (PIN). This PIN should be valid and unchangeable for a life- 
time (i.e., the PIN should not be based on changeable personal attributes such as the 
name). The PIN is the main prerequisite for being able to merge all of a person’s 
health-related information. Before a PIN can be assigned, the person must be cor- 
rectly identified (3.3.2.1). 


3.2.3.2 Entity Types About Patients’ Diseases and Their Treatment 
If persons are ill and are the subject of care, we call them patients. Certain data on 


findings and about diseases of the patients and their therapies is required for 
health care. 


Entity type | Description 


Diagnosis | Diagnoses are the identified cause or nature of patients’ diseases or medical 
conditions 


Discharge | Discharge summaries briefly summarize diagnoses, treatment, and 

summary recommendations from the discharging health care facility. The discharge 
summary is necessary for the receiving health care facilities in order to be able to 
provide further treatment 


Finding Findings summarize the results of diagnostic procedures for patients such as lab 
and X-ray examinations. Laboratory findings may consist of the measured values 
of clinical chemical parameters. But they may also contain complex genetic data 
from sequencing, also called “omics” data. Each type of data requires specialized 
software to present these data to medical personnel in such a way that they can 
interpret them well for diagnostic purposes 


Health Health records are descriptions about a person’s past and present health 

record conditions, for example, disease history, systems review, social history, past 
medical history, family history, or medication. The health record is necessary for 
health care professionals in order to make informed clinical decisions 


Image Images are rasterized representations of macro- or microscopic entities or 
processes within biological systems, generated by using different modalities (e.g., 
computed tomography, histologic slices, X-ray images) and used for diagnosis, 
prevention, therapy, and rehabilitation 


Informed Informed consent is a patient’s consent to the proposed treatment 
consent 


Medical Medical histories comprise all information collected for a patient which is needed 

history as a basis for medical care planning. The documented medical history is the result 
of medical history taking between the health care professional and the patient 

Medical Medical procedures are procedures performed by physicians for patients, for 

procedure | example, X-ray examinations or operations 

Nursing Nursing histories comprise all information collected for a patient which is needed 

history as a basis for nursing care planning. The documented nursing history is the result 


of the admission interview between the nurse and the patient 


Nursing Nursing procedures are procedures performed by nurses for patients, for example, 
procedure _| taking blood or taking the temperature 
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Entity type | Description 

Order Orders are requests made by health care professionals for diagnostic, therapeutic, 
or drug services, for example, laboratory orders or radiological orders. Orders are 
directed to health care facilities and other health care professionals 

Patient Health care facilities have records for their patients, collecting data and documents 

record related to health care in this facility. This part of the patient’s health record is 
called the patient record. Persons thus have multiple patient records if they have 
been a patient in more than one health care facility. 
Patient records are those parts of health records which are related to health care in 
a certain health care facility 

Patient Entities of the entity type “patient record archive” describe how and where the 

record patient record can be found 

archive 

Procedure | Procedures are “activities performed in the provision of health care (includes 
medical history taking, physical examination, diagnostic and therapeutic 
interventions, training and education, and counseling)” [3] 

Sample Samples are specimens taken from a patient or another person, for example, a 
blood sample or a urine sample 

Self- A self-diagnosis is a diagnosis made by an individual for his or her own condition 

diagnosis rather than by a health care professional 

Self- Self-gathered symptoms are signs or supposed signs of a disease that have been 

gathered noticed during observation of one’s own body 

symptoms 


3.2.3.3 Entity Types About Managing Health Care 


Health care 


takes place at different places. Further data is needed to organize 


this care. 

Entity type Description 

Appointment | Appointments determine what persons have to be at a certain place at a given 
time. Examples are appointments for patient admission, examination, or surgery 

Bed In health care facilities with inpatient care (e.g., hospitals and rehabilitation 
centers), beds must be managed according to their occupation 

Case The cases mostly comprise a patient’s stay in a hospital from patient admission 
to patient discharge or several outpatient treatments related to one disease. 
Information about a case includes the case identification number (CIN) 

Cost unit Cost units are organizational units of health care facilities responsible for 
bearing the costs or a part of the costs for the services to be provided for a 
patient 

Drug Drugs are substances administered to a certain patient for treatment, diagnosis, 
prevention, or rehabilitation 

Food A certain food must be provided according to different nutritional needs of 
patients, for example, normal diet and light diet food 

Material Materials such as medical strips, bandages, or needles are needed for patient 


care 
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Entity type Description 

Means of Patients may have to be transported. Certain means of transport may be, for 

transport example, stretchers, ambulances, or flying ambulances 

Medical Medical devices are technical or mechanical devices used for diagnostics and 

device treatment. Software supporting diagnostics and treatment may also be 
considered medical devices. Medical devices are subject to strict legal 
regulations (medical device regulation (MDR)) 

Patient Certain patient transports describe how and to what place a certain patient has 

transport been or must be transported 

Transfer Certain transfers describe the transfer of a certain patient, for example, by 
naming the referring physician or reasons for referring 

Room Rooms in the building of any health care setting (e.g., operating room, 
physician’s office, waiting room, or bedroom in patient’s home). Rooms have to 
be managed as a resource for patient care 

Service Health care facilities may provide non-medical services to their patients (e.g., 


internet access, transportation service) 


3.2.3.4 Entity Types About Knowledge 


It is not only information about patients that health care professionals need for care. 
Medical and nursing knowledge is also required. 


Entity type 


Description 


Available medical | Available medical and nursing knowledge is medical and nursing 


and nursing 


knowledge that is available in a wide variety of knowledge sources and can 


knowledge basically be acquired. Some available medical and nursing knowledge is 
evidence-based knowledge that is confirmed, for example, through clinical 
trials. Other available knowledge is experiential knowledge from health 
care professionals or from patients 

Classification Classifications are sets of classes summarizing concepts not to be 


distinguished during analysis. In particular, there are classifications of 
diagnoses and classifications of procedures. A classification of diagnoses 
(e.g., ICD-11 or NANDA) consists of diagnosis classes. A classification of 
medical procedures (e.g., International Classification of Health 
Interventions (ICHI)) consists of procedure classes 


Clinical pathway | Clinical pathways are evidence-based approaches describing which 


Clinical trial 


procedures are to be performed for a specific group of patients when and by 
whom 

A clinical trial is a research study testing a new treatment, medication, or 
medical device on patients. Results obtained in a trial may be used for care, 
and data recorded during care are necessary input for trials 


Nomenclature 


Nomenclatures (e.g., SNOMED CT) provide terms with codes that can be 
used to tag (or index) objects in medicine and health care. Objects may be, 
for example, cases, patients, or documents 
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Entity type | Description 


Medical and Medical and nursing knowledge comprises knowledge of various 
nursing knowledge | medical and nursing specialties, for example, knowledge about diseases, 
symptoms, side effects, treatments, and health risks. Knowledge is 
stored in physicians’ and nurses’ heads as well as in various media such 
as books, journals, guidelines, webpages, or databases. A very important 
source of medical and nursing knowledge is MEDLINE, a bibliographic 
database of medical publications. It takes a lot of effort to select and 
acquire the knowledge that a person needs for a specific task from the 
amount of available knowledge. We therefore want to distinguish 
available and selected knowledge. Furthermore, it must be taken into 
account that some knowledge is not directly available, for example, in 
the form of books and journals, but only in the form of references to 
such sources 


Acquired personal | Acquired personal medical and nursing knowledge is medical and nursing 
medical and knowledge that has been selected and acquired by a person according to his 
nursing knowledge | or her own needs in order to make decisions regarding his or her own 
health or the health of others. Here, too, some knowledge is not directly 
available but only in the form of references to the sources of the knowledge 


3.3 Domain Layer: Functions to Be Supported 


In the last section, we introduced the data typical for health care settings and 
described data by entity types. Now we will explain where and in what contexts data 
on these entity types are processed in health care settings. As explained in Sect. 2.8, 
we use information-processing functions—or short: functions—to group classes of 
information-processing activities. 

You will remember that functions use input data on certain entity types. The 
used data is updated, which often results in data on other entity types. In this 
section, we will present a selection of functions typical for health care settings 
and will explain which entity types are used and which are updated. However, 
we will not (yet) consider how they are typically supported by different data, 
information, and knowledge processing tools. This will be done in Sect. 3.4 and 
the following sections. 

In this section, you will learn about the most important functions to be performed 
by patients, informal caregivers, health care professionals, and management and 
administrative staff in health care settings. You will also learn about data that are 
used or updated by these functions. 

To illustrate which entity types a particular function uses and which it updates, 
we will use diagrams corresponding to those we also used in Sect. 2.14.1. Please 
read there again what the symbols mean. 
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3.3.1 Functions to Be Performed by Patients 
and Informal Caregivers 


In Sect. 1.2, we looked at the life situations in which people have to deal with health. 
Initially, such life situations take place in the home setting and require specific 
action by the individuals and patients concerned. Thus, in our example from Sect. 
1.4, Mrs. And Mr. Russo have to cope with their lives despite Mrs. Russo having 
broken her leg in the bathroom and Mr. Russo having a heart condition. To do so, 
they must contact with their general practitioner (GP) and with specialists to obtain 
various information. Their daughters must also participate in the care of their par- 
ents. In this context, the daughters are called informal caregivers, just like other 
relatives or friends who participate in the care of the Russos. In Sects. 1.3.1 and 
1.3.3, we had already noted what patients and informal caregivers are particularly 
concerned about in this context. 

In this section, we will now describe the information-processing tasks that 
patients and informal caregivers have to perform and what entity types are needed. 
Even though we introduced the term “function” in Sect. 2.8 in the context of health 
care professionals, it is very well-suited to also describe the information-processing 
tasks of non-professionals. The corresponding functions include but are not limited 
to (Fig. 3.4): 


e medical knowledge management, 
e self-diagnostics, 

e self-treatment, 

e arrange appointments, 

e physician’s orders filling, 

e prevention. 


3.3.1.1 Medical Knowledge Management by Non-professionals 


Patients and informal caregivers need medical and nursing knowledge, for example, 
about specific health conditions and their treatment, about diseases, symptoms, side 
effects, and about healthy lifestyles and health risks. Medical knowledge manage- 
ment by non-professionals as an information-processing function includes gather- 
ing such knowledge by consulting health care professionals as well as peers such as 
fellow patients, relatives, and friends (Fig. 3.3). The corresponding knowledge is 
gathered in the form of brochures, information material on various media, or refer- 
ences to corresponding sources and media. Patients and informal caregivers select 
units of knowledge and references to knowledge which they consider helpful. 
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Fig. 3.3. Medical knowledge management by non-professionals (for the legend refer to Sect. 2.14.1) 


As a result of medical knowledge management, patients and informal caregivers 
will have selected personal knowledge at hand—or in their mind. They must then 
organize this knowledge according to its perceived importance and relevance. 


3.3.1.2 Self-Diagnostics 


Individuals who feel ill or who are living a health-conscious lifestyle will carefully 
monitor and assess their own health conditions or the conditions of household mem- 
bers. By using the resulting self-gathered symptoms and acquired personal medical 
and nursing knowledge, they may try to identify their disease. This function, self- 
diagnostics, results in a self-diagnosis, which later may lead to self-treatment. This 
is illustrated in Fig. 3.4. 

For monitoring, individuals may use health diaries and personal digital devices, 
for example, smartphone applications that may provide automatic monitoring of 
symptoms and conditions. 


3.3.1.3 Self-Treatment 


Self-treatment usually means treating one’s own disease without direct medical 
supervision or intervention and relies on selected personal knowledge. We use this 
term here to indicate patient actions to treat their disease by themselves, for exam- 
ple, at home. Such se/f-treatment may be based on self-diagnoses or on diagnoses 
resulting from the execution of diagnostic procedures by health care professionals 
and filling the respective orders. 

Self-treatment includes physical exercise, managing prescribed medication and 
self-medication, and using digital health applications (DiGAs) to support mental 
health, for example. 

Self-treatment may also include prevention, which is better than cure. Many dis- 
eases result from unhealthy lifestyles and behavior. A change in behavior can there- 
fore both prevent and, in many cases, make a significant contribution to curing 
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Fig. 3.4 Summary of functions to be performed by patients and informal caregivers (for the leg- 
end refer to Sect. 2.14.1) 
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diseases. Prevention through healthy behavior is an important contribution to one’s 
own health, which can be done very well in one’s own responsibility, especially in 
the home environment. Prevention includes using guidelines, reporting outcomes in 
diaries, and organizing appointments for training and advice as well as for transport 
to or from a health care facility providing support. 


3.3.1.4 Arrange Appointments 


Either because of a self-made diagnosis or on the basis of a physician’s diagnosis 
and order, it may become necessary to visit a certain health care facility. This could 
be, for example, an initial consultation with the family physician, a referral to the 
radiologist for a radiological examination, or a visit to a physiotherapist. In any 
case, it is usually necessary to arrange an appointment beforehand. This can be very 
demanding for the patient if several facilities have to be contacted in order to obtain 
a timely appointment. Patients may use phones, physicians’ websites, or even spe- 
cialized apps for this function. 


3.3.1.5 Filling Physician’s Orders 


A visit to a physician usually involves the physician recommending that the patient 
take certain measures. For example, they may propose that the patient see a special- 
ist, receive a specific physiotherapeutic treatment, take a set of medicines in a spe- 
cific order, or take preventive measures by changing unhealthy behavior. It is often 
a challenge for the patient to both remember these orders and organize their imple- 
mentation. Compliance with the measures prescribed or recommended by a physi- 
cian or therapist is referred to as adherence. 
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3.3.2 Functions to Be Performed by Health care Professionals 
and Other Staff in Health care Facilities 


3.3.2.1 Patient Care 


Patient care in a facility begins with the patients’ admission and ends with their 
discharge and any necessary transfer to another facility. During the patients’ stay at 
the facility, decisions must be made about the diagnostics and therapy to be exe- 
cuted, and appropriate procedures must be ordered. The data generated during treat- 
ment must be coded so that it can be further processed. 


Patient Admission 


The prerequisite for the treatment of a sick person by a health care professional in a 
health care facility is the admission of the person to that facility. Patient admission 
(short: admission) aims at recording and distributing the patient demographic and 
insurance data as well as data on the medical and nursing history (Sect. 3.2.3.2). In 
addition, each patient must be identified correctly and a unique patient and case 
identification number (CIN) must be assigned. 

This function can be decomposed as follows (Fig. 2.4 in Sect. 2.14.1): 


Appointment Scheduling 


The health care facility must schedule an appointment for the patient’s visit. 
Appointments must also be made in connection with order entry for diagnostic 
services in a radiology department, for example. 

In addition, unplanned patient admissions must be possible (e.g., in case of 
emergencies). 


Patient Identification 


Before health care professionals treat a patient, they must be sure exactly who 
the person they are treating is. Patients will normally identify themselves or 
with the assistance of relatives through a health insurance card or identity card. 
Based on such documents, the health care professional or administrative staff 
of the respective health care facility assigns a unique PIN to the patient. A new 
PIN is assigned only if the patient is in the facility for the first time. If patients 
have already been in the facility, they must be identified as recurrent, and pre- 
viously documented information must be made available (such as previous 
diagnoses and therapies). Hospitals, in particular, must be able to distinguish a 
patient’s different cases or hospital stays. Therefore, in addition to the PIN, a 
case identification number (CIN) is usually assigned as part of administrative 
admission. 
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Merging all health-related data and documents of a particular patient can only 
succeed if all health care professionals and all health care facilities caring for the 
patient use the same PIN. If each facility assigns its own PIN to a patient, a tool is 
needed to map the different PINs of one patient to each other. Such an application 
system is called a master patient index (MPI) and will be discussed in Sect. 3.4.1. 
Some countries provide a single unique PIN for every citizen, for example, on the 
health insurance card. 

Patient identification as a function therefore interprets the entity type “patient” 
by considering, for example, their name, birthday, and data from the ID card and 
updates the same entity type by updating the PIN. 


Administrative Admission 


Administrative admission starts following patient identification. It creates the so- 
called case, being the aggregation of several contacts clustered according to specific 
clinical and/or organizational purposes of the facility. In case of inpatient treatment, 
a case summarizes the stay at the facility from patient admission until discharge. 
Each case is uniquely identified by its CIN. Important administrative data, such as 
insurance data or details about booked services, patient’s relatives, admitting physi- 
cian, and transfer diagnoses, must be recorded. The patient is assigned to a certain 
area, for example, a ward and a bed. Some of the administrative data must be avail- 
able to other functions through the help of certain organizational media (such as 
adhesive labels and smart cards). Administrative data form the backbone of infor- 
mation processing in a health care facility. In case of changes, patient data must be 
maintained and communicated. If the referring physician, for example, the GP, has 
communicated relevant information (e.g., previous laboratory findings), this infor- 
mation must be sent to the responsible physician in the admitting facility. In hospi- 
tals, administrative admission is usually done either in a central patient admission 
area by administrative staff or directly on the ward (e.g., during emergencies or on 
the weekend) by health care professionals. In medical offices, there is usually a 
reception desk where this function is performed. 

Even in emergencies, patient admission is necessary. At the very least, patient 
identification must be performed in order to assign a proper PIN and CIN. In emer- 
gencies, a short version of administrative admission may be applicable. If the 
patient is unconscious and does not have an identity card, a dummy name may be 
recorded to provide PIN and CIN. If using PIN and CIN properly, there will be no 
problem to replace the dummy name by the correct name later on. 


Medical Admission 


At the first contact with the patient, the physician will carry out the medical admis- 
sion. This typically comprises recording the patients’ medical history (disease his- 
tory, systems review, social history, past medical history, family history, medication). 
Some of this information may be collected from documents of the referring physi- 
cian which are taken to the facility by the patients themselves. 
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As a result of medical admission, the admission diagnosis must be stated and 
coded using the mandatory classification, for example, ICD-11. 

The medical history must be made available for other functions by including it 
with the patient’s health record. However, some facilities only have access to 
patient-related documents and data that originated from the same facility, i.e., the 
facility’s patient record. 


Nursing Admission 


Especially in the case of inpatient treatment in a hospital, nursing home, or rehabili- 
tation center, the nurse in charge will proceed with the nursing admission at the 
ward. This typically comprises introducing the patient to the ward and recording the 
nursing history. Administrative data and the reason for hospitalization are already at 
the nurse’s disposal. The nursing history contains information about the current 
diagnosis and therapy, orientation, communication ability, social contacts, nutrition, 
mobility, personal hygiene, and vital signs. Computer-based or department-specific, 
(semi-) standardized data entry forms may be available to collect the data. The col- 
lected data must be made available for the whole stay by including it in the patient’s 
health record. 


Visitor and Information Service 


In any health care facility that provides inpatient care, administration must have a 
good overview of the recent bed occupation, i.e., about the patients’ stay at the hos- 
pital. This is, for example, important for the clerks at the information desk, who 
must be able to inform relatives and visitors correctly, as well as for some general 
administration statistics. 


Decision-Making, Planning, and Organization of Patient Treatment 


The treatment of the patient requires the execution of a variety of diagnostic and 
therapeutic procedures. Health care professionals must decide with the patient 
which procedures to execute based on available data and knowledge. Then these 
procedures must be carefully planned and initiated. This process is repeated each 
time new information and knowledge is available. 

This function can be decomposed as follows (Fig. 3.5): 


Decision-Making and Patient Information 


Health care professionals must decide on the next steps to take, for example, certain 
diagnostic or therapeutic procedures. Depending on the complexity of a diagnostic 
or therapeutic decision, they should be able to consult internal or external experts 
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Fig. 3.5 Function decision-making, planning, and organization of patient treatment, its subfunc- 
tions and interpreted and updated entity types (for the legend refer to Sect. 2.14.1) 
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(e.g., in specialized hospitals) to obtain a second opinion. In this context, (tele)con- 
ferences may help. Health care professionals must be able to access all relevant 
patient data specific to a situation in addition to general medical and nursing knowl- 
edge (e.g., guidelines, recent study results and standards). Medication prescription 
may be supported by providing knowledge about adverse drug events. Decisions 
about clinical procedures must be documented. Patients must be involved in the 
decision-making process, the consequences of the planned diagnostic or therapeutic 
procedures should be explained, and their informed consent must be documented. 
Decision-making is a permanent function that is triggered by new information about 
the patient and the availability of new knowledge. 


Medical and Nursing Care Planning 


The next steps must be planned in detail. For each medical procedure (such as a 
radiological examination, an operation, or a chemotherapeutic treatment) as well as 
for each nursing procedure, the type, extent, duration, and responsible person and 
facility have to be determined. In nursing, care planning is documented in nursing 
care plans containing nursing problems, nursing goals, and planned nursing proce- 
dures. If necessary, other health care professionals are ordered to execute the 
planned procedures (e.g., a physician’s medical bandaging orders to be executed by 
a nurse or home care service at the patients’ home). 

Care planning in cancer treatment is often performed by tumor board reviews. 
This means that a number of physicians who are experts in different specialties 
(disciplines) review and discuss the patient’s medical condition and treatment 
options. 
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Order Entry 


Diagnostic and therapeutic procedures must often be ordered at specialized service 
units (e.g., laboratory, radiology, or pathology). These units may be an internal part 
of the health care facility of the treating health care professional or may be an exter- 
nal institution. The units execute the ordered procedures and communicate the find- 
ings or results back to the ordering facility. In order to avoid mix-ups, all units and 
facilities involved must use the same PIN. This is especially challenging when the 
service units do not belong to the same facility. 
This function can be decomposed as follows (Fig. 3.6): 


Preparation of an Order 


If the order is to examine the patient’s tissue or fluid samples, the specimen must be 
unambiguously assigned to a patient and then submitted (e.g., blood sample). 
Depending on the available service spectrum offered by a service unit, which may be 
presented in the form of service catalogs, the health care professional selects the 
appropriate service on an order entry form. Patient identification data (name, PIN) 
are documented together with relevant information such as recent diagnoses, relevant 
questions, service ordered (e.g., lab test), and other comments (e.g., on special risks). 

If a medication is ordered by a physician and computer-based tools for order 
entry are used, computerized decision support systems could alert the physician, for 
example, in case of medication errors when a medication is ordered to which the 
patient is allergic. 

The order may only be initiated by authorized persons. The order must be trans- 
mitted quickly and correctly to the service unit or to the person who is to execute the 


Medical and nursing Service 
knowledge catalogue m 
Preparation of 
an order 

Order entry 
1 
1 
1 
1 
1 
1 


Appointment 
scheduling 


Appointment 


Fig. 3.6 Function “order entry,” its subfunctions and interpreted and updated entity types (for the 
legend refer to Sect. 2.14.1) 
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order. If a specimen is transferred, it must be guaranteed that the order and the speci- 
men can be linked to each other at the service unit. It should be possible for the 
ordering health care professional to modify orders that have already been trans- 
ferred, if necessary. 


Appointment Scheduling 


The patient’s appointments must be scheduled (e.g., in radiological units) depending 
on the type of order. During scheduling, the demands of all parties (e.g., ordering phy- 
sician, service unit, patient, transport unit, public transport) must be fairly balanced. 
This can be particularly challenging in the context of outpatient care if, for example, a 
suitable radiologist must first be found near the patient’s place of residence and pos- 
sible examination dates must be determined. It can also be complicated to have the 
patient transported to the radiologist. Depending on the health care system, patients 
may have to handle these tasks themselves and it becomes their function (Sect. 3.3.1). 


Execution of Diagnostic, Therapeutic, and Nursing Procedures 


The planned diagnostic, therapeutic, or nursing procedures (such as operations, 
radiotherapy, radiological examinations, medication) must be executed. Adequate 
tools and resources (e.g., staff, room, equipment) for the execution of the necessary 
procedures have to be available. This must be managed according to the special 
needs of the respective facility and health care setting (Chap. 6). 

It is important that changes in care planning that may be due to new findings are 
promptly communicated to all involved units, facilities, and persons, enabling them 
to adapt to the new situation. All clinically relevant patient data (such as vital signs, 
orders, results, decisions) must be recorded as completely, correctly, and quickly as 
necessary. This supports the coordination of patient treatment among all persons 
and facilities involved and provides the legal justification for the actions taken. In 
inpatient care, a lot of these data may be recorded, for example, on the ward. In 
outpatient care, however, with the health care professionals caring for the patient at 
home, much of the data must also be collected and documented at the patient’s home. 

As far as possible and whenever sensible, data and metadata should be recorded 
and represented in a standardized manner (compare 3.2.2) to allow for seamless 
care across providers, for data aggregation and statistics, for computerized decision 
support, and for data retrieval. It is important that data can be linked by PIN and 
CIN even when data originate from different areas (such as ward, service unit, out- 
patient unit, home). The health care professionals and their facility must usually 
fulfill a lot of different legal reporting (such as for epidemiological registers) and 
documentation requirements. The items to be documented depend partly on the 
documenting unit and the documenting health care professional group (such as doc- 
umentation by physicians or nurses, in outpatient units, in operation rooms, or in 
patients’ homes). Clinical information should also be available for other functions 
such as financial accounting, controlling, or quality management. 

This function can be decomposed as follows (Fig. 3.7): 
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Fig. 3.7 Function execution of diagnostic, therapeutic, and nursing procedures, its subfunctions 
and interpreted and updated entity types (for the legend refer to Sect. 2.14.1) 


Execution of nursing 
procedures 


Execution of Diagnostic and Therapeutic Procedures 


The planned diagnostic and therapeutic procedures must be executed. All proce- 
dures must be documented. Findings and reports must be transmitted (as quickly as 
necessary) back to the ordering unit and presented to the responsible health care 
professional. They must be unambiguously assigned to the correct patient. The 
responsible physician should be informed about new results, and critical findings 
should be highlighted. 

The function execution of diagnostic and therapeutic procedures can be spe- 
cialized to: 


e execution of operations, 

e execution of intensive care, 

e execution of irradiation, 

e execution of chemotherapy, 

e execution of radiological examinations, 

e execution of lab examinations, 

e execution of prophylaxis and medication. 


Execution of Nursing Procedures 


The planned nursing procedures (concerning medication, excretion, decubitus, 
hair and nail care, skin care, wound treatment, body washing, oral and dental care, 
nutrition and liquid balance, thrombosis) are executed. All patient care 
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procedures, their impact on the patient’s health status, and changes to the care 
plan must be documented. The responsible physician must be informed of any 
facts relevant to the therapy. 


Coding of Diagnoses and Procedures 


The health care facility must be able to document and code all stated diagnoses and 
all executed medical procedures in a correct, complete, quick, and patient-oriented 
way. These data form the basis for billing, for reports, and for research. Diagnoses 
and medical procedures are also used for controlling. In addition, legal require- 
ments stipulate that some of the data must be documented and communicated. This 
data is also important for medical research. 

Diagnoses and medical procedures are recorded and coded in a standardized way 
(e.g., using the ICD11 for diagnoses codes [4]) and then processed. Diagnoses and 
medical procedures are at least partly derivable from clinical documentation. To 
support their documentation, adequate coding catalogs must be offered and main- 
tained. Tools are needed that help health care professionals to quickly find the cor- 
rect codes for the diagnoses and medical procedures. 

The function coding of diagnoses and procedures, its decomposition in subfunc- 
tions, and the entity types to be interpreted and updated are summarized in Fig. 3.8. 
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Fig. 3.8 Function coding of diagnoses and procedures, its subfunctions and interpreted and 
updated entity types (for the legend refer to Sect. 2.14.1) 
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Fig. 3.9 Function patient discharge and transfer to other facilities, its subfunctions and inter- 
preted and updated entity types (for the legend refer to Sect. 2.14.1) 


Patient Discharge and Transfer to Other Facilities 


In case of inpatient care in a health care facility after the patient’s care has been 
completed, the patient is discharged and sometimes referred to other facilities (e.g., 
GPs or rehabilitation centers). Patient discharge and transfer to other facilities 
(short: discharge) covers administrative, medical, and nursing discharge. 

This function can be decomposed as follows (Fig. 3.9): 


Administrative Discharge and Billing 


The process of administrative patient discharge initiates final billing and the fulfill- 
ment of legal reporting requirements (e.g., statistics on diagnoses and procedures). 
In recent years, diagnosis-related group (DRG) systems have been introduced for 
patient billing in most countries. That means that bills for patient treatment are no 
longer calculated based on daily rates but on the DRG in which a patient case was 
classified. Diagnoses, procedures, patient’s age, and other criteria serve as an input 
for the calculation of a DRG. 


Medical Discharge and Medical Discharge Summary Writing 


Medical discharge entails the completion of the documentation and the writing of a 
discharge summary by the attending physician. The discharge summary includes 
the relevant diagnoses, important findings, therapeutic procedures, current patient 
state, and recommendations for further treatment. The hospital must be able to 
transmit this and other information (e.g., radiological images) to other facilities as 
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quickly as possible. To speed up this process, a short report (i.e., physician’s dis- 
charge letter) is often immediately communicated to the next facility containing, for 
example, the diagnoses and therapeutic treatments. It is then later followed by a 
more detailed report. 


Nursing Discharge and Nursing Discharge Summary Writing 


Nursing discharge entails the completion of the documentation and the writing of a 
nursing discharge summary by the attending nurse. The nursing discharge summary 
comprises, for example, information about activity level, diet, and wound care. 


3.3.2.2 Supply and Disposal Management, Scheduling, 
and Resource Allocation 


The health care facility must offer sufficient and well-organized resources for 
patient care. This is true for wards (ward management), outpatient units (outpa- 
tient management), and service units (department management). Efficient pro- 
cess organization is extremely important, for example, in outpatient units or 
service units, and can be supported, for example, by providing working lists for 
individual staff members by issuing reminders about appointments or by visual- 
izing actual process flow. The facility’s information system must be able to sup- 
port communication between all persons involved in patient care. This comprises 
synchronous (e.g., telephone) and asynchronous (e.g., blackboards, brochures, 
email) communication. Staff members must be able to be contacted within a pre- 
scribed period of time. 


Supply and Disposal Management 


Supply and disposal of materials, food, drugs, and so on must be guaranteed. All of 
a facility’s departments should be able to order from up-to-date catalogs. The cor- 
responding service units (stock, pharmacy, and kitchen) must be able to deliver 
correctly and on time. 

Supply and disposal management can be decomposed as follows (Fig. 3.10): 


e Catering 
According to their health status, patients have different nutritional needs. It 
must be ensured that the patients are provided with the right dietary food at the 
right time. 
e Material and medication management 
Nurses and physicians must be able to anticipate shortages of material such as 
medical strips, bandages, or needles to order new material from a central supplier 
in time. 
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Fig. 3.10 Function supply and disposal management, its subfunctions and interpreted and updated 
entity types (for the legend refer to Sect. 2.14.1) 


e Laundry management 
The hospital must permanently be supplied with linen, towels, sterile scrubs, 
surgical masks, etc. 
e Management of medical devices 
In addition to other resources, medical devices must be registered and main- 
tained according to legislation. Due maintenance must be organized, docu- 
mented, and completed. 


Scheduling and Resource Allocation 


Various resources are needed for patient care in health care facilities. The function 
scheduling and resource allocation comprises staff planning, bed planning, room 
planning, and device planning. All resource planning activities must be coordinated. 
When procedures are scheduled, the demands of both the service unit and the order- 
ing unit with regard to scheduling the appointment must be considered. Request, 
reservation, confirmation, notification, postponement, and cancellation must be 
supported. All involved staff members and patients should be informed about the 
appointments. Postponements and cancellations should be communicated to all 
involved persons in time. 

This function can be decomposed into the functions appointment scheduling, 
scheduling and resource planning with the medical service unit, and scheduling and 
resource planning with the patient transport service (Fig. 3.11). Appointment sched- 
uling was also listed as a subfunction of patient admission. 
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Fig. 3.11 Function scheduling and resource allocation, its subfunctions and interpreted and 


updated entity types (for the legend refer to Sect. 2.14.1) 
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Fig. 3.12 Function human resources management, its subfunctions and interpreted and updated 


entity types (for the legend refer to Sect. 2.14.1) 


Human Resources Management 


This contains all tasks for the development and improvement of the productivity of 
staff. It comprises, for example, staff and position planning, the staff register, staff 


scheduling, and staff payroll. 


This function can be decomposed as follows (Fig. 3.12): 


e administration of human resource master data, 


e human resource planning, 
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e work organization and time management, 
e payroll accounting, 
e administration of business trips and further training. 


3.3.2.3 Administration of Health care Facilities 


Administration of health care facilities supports the organization of patient care and 
guarantees the financial survival and the economic success of the hospital. 
Subfunctions are: 


Patient Administration 


Patient administration comprises the administrative tasks in a health care facility 
dealing more or less immediately with patients. Thus, it is an aggregation of the 
subfunctions 


e appointment scheduling, 

e administrative admission, 

e patient identification, 

e visitor and information service, 

e coding of diagnoses and procedures, 

e administrative discharge and billing (Fig. 3.13). 


Archiving of Patient Information 


Relevant data and documents containing patient information must be created, gath- 

ered, presented, and stored in such a way that they are efficiently retrievable during 

the whole process of patient treatment. These data and documents are primarily 

stored in patient records. A mixture of paper-based and computer-based patient 

records is still used today. Certain legal requirements usually must be considered. 
This function can be decomposed as follows (Fig. 3.14): 


e Opening of a patient record 
Administrative admission triggers the opening of a patient record. The patient 
record may be electronic or paper-based or a mixture of both. Standards for 
document filing formats must be established and used. 
e Administration and allocation of patient records 
A paper-based archive must be able to manage patient records and make them 
available upon request within a defined time frame. The exact location of each 
record should be known (e.g., in which archive, on which shelf). Robot systems 
may store and gather paper-based records automatically. Lending and return of 
records (e.g., for patients coming for multiple visits) must be organized, while 
respecting different access rights that depend on the role of the health care pro- 
fessionals in the process of patient care. 


3.3 Domain Layer: Functions to Be Supported 


Administrative 
Scheduling 


Administrative 
admission 


Patient 


Patient identification 


administration 


A y 


Visitor and 
information service 


Coding of diagnoses le 


77 


Resource 


and procedures 


1 
1 
1 
1 
1 
1 
1 
1 ~ 
i 
i 
1 
i 
1 
1 
1 
1 


Administrative 
discharge and billing 


Diagnosis 
Procedures 


Fig. 3.13 Function patient administration, its subfunctions and interpreted and updated entity 
types (for the legend refer to Sect. 2.14.1) 
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Fig. 3.14 Function archiving of patient information, its subfunctions and interpreted and updated 
entity types (for the legend refer to Sect. 2.14.1) 
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e Long-term archiving 
After discharge of the patient, patient records must be archived for a long time 
(e.g., for 10 or 30 years, depending on the legal regulations). The archive must 
offer enough space to allow the long-term storage of patient records. Their 
authenticity and correctness can be proven more easily, for example in case of 
legal action, if they are archived in accordance with legal regulations. 


Quality Management 


Quality management comprises all activities of a health care facility’s administra- 
tion to assure and continuously improve the quality of patient care. This includes 
setting goals, defining responsibilities, and establishing and monitoring the pro- 
cesses to realize these goals. This covers, for example, internal reporting containing 
quality indices. Quality management requires information about patients and treat- 
ments as well as knowledge about diagnostic and therapeutic standards. 

This function can be decomposed as follows (Fig. 3.15): 


e Internal quality management 
Internal quality management assures a defined quality of all processes and 
outcomes of the hospital. An internal reporting system, which presents quality- 
related indicators, is also covered. Medical, nursing, and administrative guide- 
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Fig. 3.15 Function quality management, its subfunctions and interpreted and updated entity types 
(for the legend refer to Sect. 2.14.1) 
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lines may be defined, stored, and presented. There exists a structured complaint 
management. 
e Performance of legal notification requirements 
Legal notification requirements for quality assurance must be completed. 


Cost Accounting 


For controlling purposes, it is necessary to keep track of services, their costs, and 
who has received the services. Cost accounting usually investigates which costs 
incur (cost-type accounting), where costs incur (cost center accounting), and for 
what activities or services costs incur (cost unit accounting). According to the 
accounting purpose, the time period to be observed and the scope of the costs to be 
accounted have to be defined. The results of cost accounting, i.e., key performance 
indicators (KPI), serve as input for controlling (Figs. 3.16 and 3.17). 
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Fig. 3.17 Function controlling, its subfunctions and interpreted and updated entity types (for the 
legend refer to Sect. 2.14.1) 


Controlling 


The health care facility must be able to gather and aggregate data on its operation in 
order to control and optimize it. This covers, for example, staff controlling, process 
controlling, material controlling, and financial controlling. In hospitals, for exam- 
ple, the number of patient cases, the length of patients’ stays in the hospital, and the 
case mix index, which is calculated from the patients’ DRGs, are KPIs serving as 
input for controlling reports (Fig. 3.17). 


Financial Accounting 


All the facility’s financial operations must be systematically recorded to meet legal 
requirements. Financial accounting comprises, for example, debtor accounting, 
credit accounting, and asset accounting. This type of accounting requires informa- 
tion from bills and creates new values for KPIs (Fig. 3.18). The health care facility 
must support general statistical analysis, for example, calculation and analysis of 
economic data. 
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Fig. 3.18 Function financial accounting, its subfunctions and interpreted and updated entity types 
(for the legend refer to Sect. 2.14.1) 


Fig. 3.19 Function facility 
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Facility Management 


The management of buildings, areas, and utilities of the health care facility is usu- 
ally subsumed by the term facility management. As this often also involves high 
costs, this management area also influences KPIs (Fig. 3.19). 


Management of Information Systems! 


Management of information systems plans the information system of an enterprise 
and its architecture, directs its establishment and its operation, and monitors its 
development and operation with respect to the planned objectives. Different man- 
agement levels have different perceptions and interests. 


! Now we have come full circle. Our book deals with information management and especially stra- 
tegic information management. Since information systems are the subject of information manage- 
ment, and information systems are designed to support all necessary functions of an enterprise, 
they should support information management as well. For a more thorough explanation of strategic 
information management, refer to Sect. 4.3. 
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Fig. 3.20 Function management of information systems, its subfunctions and interpreted and 
updated entity types (for the legend refer to Sect. 2.14.1) 


This function can be decomposed as follows (Fig. 3.20): 


e Strategic management of information systems 
Strategic management of information systems deals with the enterprise’s 
information processing as a whole and establishes strategies and principles for 
the evolution of the information system. An important result of strategic manage- 
ment activities is a strategic information management plan that is aligned with 
the hospital’s business strategy. It includes the direction and strategy of informa- 
tion management and the architecture of the enterprise information system. 
e Tactical management of information systems 
Tactical management of information systems deals with particular functions 
or application components that are introduced, removed, or changed. Usually, 
these activities are done in the form of projects. Such tactical information man- 
agement projects are initiated by strategic management of information systems. 
Thus, strategic management of information systems is a vital necessity for tacti- 
cal management of information systems. The result of tactical information man- 
agement projects is the information system. 
e Operational management of information systems 
Operational management of information systems is responsible for operating 
the components of the information system. It ensures its smooth operation in 
accordance with the strategic information management plan. Additionally, oper- 
ational information management plans, directs, and monitors permanent JT ser- 
vices for the users of the information system. 
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Fig. 3.21 Function management of health care facilities, its subfunctions and interpreted and 
updated entity types (for the legend refer to Sect. 2.14.1) 


3.3.2.4 Management of Health care Facilities 


Management of health care facilities decides on questions of fundamental impor- 
tance for the health care facility’s development (goals, strategic decisions, personnel 
decisions and decisions about budget, investments, or key treatments). Management 
of health care facilities must focus on high quality of patient care, taking into 
account economic as well as legal and other requirements. Information needed and 
produced is shown in Fig. 3.21. 


3.3.2.5 Clinical Documentation: A Function? 


It may be surprising that “documentation” is not listed as a function in the previous 
sections. In fact, clinical documentation, which comprises medical documentation 
and nursing documentation, is a time-consuming and often unpopular duty of health 
care professionals. Moreover, every function described so far requires a lot of docu- 
mentation. The results of diagnostic procedures have to be written down, medical 
histories have to be documented, and so on. Documentation takes place every time 
a function is performed, new information is generated, and respective data are stored 
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somehow somewhere. Thus, every introduced function which updates an entity type 
is a documenting function. In fact, documentation is a part of all functions updating 
an entity type, even of those performed by patients. 


3.4 Logical Tool Layer: Types of Application Systems 
in Health care Facilities 


After having looked at data to be processed and at functions to be performed we 
now describe tools for data, information, and knowledge processing at the logical 
tool layer of information systems, i.e., the application components supporting these 
functions and storing and processing the data. 

Health care facilities still have non-computer-based application components and 
use paper as a physical tool. For example, parts of clinical documentation while 
performing functions are occasionally still done with paper-based patient records. 
Thus, despite the growing portion of electronic documents, the “paperless hospital” 
still seems to be a remote ideal today. There might be a continuing need for some 
paper-based documents. Typical application components that are still paper-based 
comprise, for example, the patient chart, the patient record, and clinical text books 
and knowledge sources. 

In spite of this still existing significance of non-computer-based information pro- 
cessing in health care, we will focus here on application systems, i.e., the computer- 
based application components. 

In Sect. 3.3.2, we could see that many functions are commonly found in all health 
care facilities. Although they use different application systems to support the func- 
tions, there are typical application systems to support health care professionals in 
health care facilities. We take a closer look at the respective types in the following 
subsections. In Sect. 6.8, however, we will look at types of application components 
to support patients and informal caregivers. 

We will sum up the characteristics of the application systems in tables enumerat- 
ing the supported functions; please refer to Sect. 3.3 for their detailed descriptions. 
For every function, we also list typical features that the application system should 
offer. A feature is a functionality offered by the application system’s software which 
directly contributes to the fulfillment of one or more functions (Sect. 2.9). 

Please note that we refer to some of the application system types as “XYZ infor- 
mation system” (e.g., laboratory information system). Although this sounds contra- 
dictory to our definition of the term “information system,” we did so in order to 
integrate the popular names and hope you will not be confused. 

In this section, you will get to know the types of application systems that are used 
in health care. In later Sects. 3.5-3.9, we will explain step by step how and under 
which conditions the application systems described here can be assembled, i.e., 
integrated, in the information system. Finally, in Sect. 3.10, we will discuss the 
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physical data processing systems on which the application systems need to be 
installed. Finally, in Chap. 6, we will take a closer look at specialized application 
systems in specific health care settings. 


3.4.1 Patient Administration Systems 


Whether hospital, medical office, or rehabilitation center, a health care facility 
needs to administer patients. Patient administration comprises the functions from 
Sect. 3.3.2.3.1 as listed in Table 3.1. 

Application systems supporting patient administration are referred to as patient 
administration systems or sometimes “patient management systems.” They must 
provide correct, complete, and up-to-date administrative patient data for all other 
application components. In addition, all other application components must be able 
to transmit relevant administrative patient data (e.g., diagnoses) to the patient 
administration system. Therefore, the patient administration system can be regarded 
as the center of the administrative memory of the facility’s information system. 


Table 3.1 Set of functions and related features typically to be supported by patient 
administration systems 


Function (from Sect. 


3.32) Typical application component features 

Appointment Provide means for scheduling patients’ appointments 

scheduling Provide means for ordering transport services 

Administrative Provide forms for entering or updating patient administrative 
admission information (name, address, birthdate, relatives, admission diagnosis, 


etc.) 

Merge patient information from two records 

Provide means for ordering patient transfer within the facility 
Admit patients to the ward or outpatient unit 

For inpatient care: assign patients to rooms and beds 

Provide means for preparing facility-wide statistics 


Patient identification 


Retrieve patient information from database 
Generate a unique PIN and a CIN 
Administrate the transinstitutional PIN 


Visitor and 
information service 


Provide relatives with information on the location of a patient 


Coding of diagnoses | Provide catalogs and other means for coding patients’ diagnoses 
and procedures Provide catalogs and other means for coding patient-related procedures 
Provide means for verifying codings done in departments 
Provide forms for preparing a bill for the patient insurance 
Administrative Provide means for initiation of final billing for inpatients and 
discharge and billing | outpatients 


Provide reminder for fulfilling of legal reporting requirements 


86 3 Technological Perspective: Architecture, Integration, and Standards 


During patient admission, patient administration systems must support the 
retrieval of patient data (e.g., by name or birthdate) to avoid duplicate and erroneous 
registration of patients. The resulting identification numbers PIN and CIN are of 
utmost importance for the whole information system. They are the basis for correct 
assignment of patient-related data to patients and thus are the very precondition for 
a valid patient record—tegardless if it is electronic or not. Without correct PIN and 
CIN, all the high-tech of a modern information system would be useless. 

Application systems providing a correct PIN are often called MPI. Hence, a 
patient administration system is an MPI. It is essential to have exactly one MPI in a 
health information system—regardless whether it is an institutional health informa- 
tion system where the MPI provides the PIN or a transinstitutional health informa- 
tion system (tHIS) where the MPI provides the transinstitutional PIN and, if 
necessary, cross-references the institutional PINs. 

Both PIN and CIN as well as the related patient information must be made avail- 
able to other application components of the facility. If the patient already has a 
paper-based patient record, the application component should automatically trigger 
the transfer of this record from the patient record archive to the unit the patient has 
been admitted to. 

In addition, patient administration systems may update patient information in 
case of changes or merge patient information from two cases if a new PIN was 
wrongly assigned to a patient. 

Patient administration systems are usually not only used by administrative staff 
but also by nurses and doctors at the ward. In the latter case, they also support daily 
management activities by health care professionals that occur on a ward. In particu- 
lar, they support the assignment of patients to beds and rooms with the features 
shown in Table 3.1. 

Some countries have different regulations for inpatient and outpatient billing. 
Particular features may therefore be needed for billing in outpatient departments 
and medical offices. 


3.4.2 Medical Documentation and Management 
Systems (MDMS) 


In addition to a patient administration system to support the management of patients, 
health care facilities need another application system to support functions related 
more closely to organizing and documenting patients’ diagnostics and treatment. 
These functions are summarized in Table 3.2. 

Application systems designed to especially support the functions in Table 3.2 
are called medical documentation and management systems (MDMS). They typi- 
cally contain specialized modules for different medical fields (e.g., ophthalmol- 
ogy, psychiatry, dermatology) and usually offer generic forms for free text, 
semi-structured, or structured (e.g., drop-down lists) data entry for medical 
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Table 3.2 Set of functions and related features typically to be supported by medical documentation 
and management systems 


Function (from Sect. 3.3.2) | Typical features 


Medical admission Provide forms for documenting medical history 
Provide forms for documenting diagnosis 
Scan documents from referring physician and other sources 


Decision-making, planning, Provide forms for documenting patient’s informed consent 
and organization of patient Provide forms for documenting planned tasks 
treatment Provide guidelines for care planning 

Provide context-related medical knowledge 
Execution of diagnostic and Provide forms for entering clinical data (free text or structured) 
therapeutic procedures Provide forms for preparing findings 


Medical discharge and medical | Provide means for writing the discharge summary, for 
discharge summary writing example, by collecting and presenting available data which 
should be compiled for the summary 

Provide means for finalizing documentation 


Human resources management | Provide means for managing staff 
Create a roster 
Assign doctors to patients or rooms 


Coding of diagnoses and Algorithm for finding correct codes for diagnose and 
procedures procedures given in natural language 


documentation as well as support for speech recognition, reporting, and analysis 
features. The more data are structured, the easier patient-related computer-based 
decision support and statistical data analysis are. It is important that users are able 
to adapt the features to their needs (e.g., by defining which items have to be docu- 
mented and which constraints the entered data must meet). When reports are gen- 
erated, the reuse of already-documented data (e.g., diagnoses, findings from 
radiology, or lab) should be supported. 

Besides clinical documentation, the coding of diagnoses and procedures is very 
important. Coding components must support the easy search for suitable diagnosis 
and procedure classes and their respective codes in classifications for a given medi- 
cal field. Alternatively, free text can be analyzed using natural language recognition 
methods. If these coding components are separate from the MDMS, it must be guar- 
anteed that the codes can be transferred to MDMS. The MDMS should also allow an 
adequate layout of diverse reports. When several persons are involved in the cre- 
ation of a report (e.g., discharge summaries may be dictated by a junior physician, 
written by a secretary, and approved by a senior physician), the application compo- 
nents should support the management and distribution of different versions of a 
document having different status (e.g., preliminary or approved). 

Medical documentation is the basis for decision-making, planning, and organiza- 
tion of patient treatment. The MDMS must therefore support the medical staff by 
providing medical knowledge, which should be preselected using documented data 
about the patient’s conditions. Ideally, a respective “infobutton” [5] should be 
implemented. 
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3.4.3 Nursing Management and Documentation 
Systems (NMDS) 


Although patient treatment and patient care or nursing are inherently intertwined, 
these two areas are often considered separately, even in information systems. 
Corresponding to the areas of responsibility of physicians and nurses, a distinction 
is also made, for example, between medical informatics and nursing informatics. 
Unfortunately, this often also results in other application systems being used to sup- 
port the nursing process, even though doctors and nurses need to work together 
particularly closely. 

The nursing process comprises nursing admission, nursing care planning with 
definition of problems, formulation of nursing aims, and planning of nursing tasks, 
then execution of nursing procedures and nursing discharge and nursing discharge 
summary writing. Like medical diagnoses and procedures, nursing diagnoses and 
procedures must be coded. The working hours of nursing staff, who usually work in 
shifts, must be carefully managed. These functions, together with related features, 
are listed in Table 3.3. 

Application systems designed to especially support the functions in Table 3.3 are 
referred to as nursing management and documentation systems (NMDS) or some- 
times “nursing information system.” 


Table 3.3 Set of functions and related features typically to be supported by nursing management 
and documentation systems 


Function (from Sect. 3.3.2) Typical features 


Nursing admission Provide forms for documenting the nursing history 
Medical and nursing care Support creation of a nursing care plan 
planning Provide forms for documenting diagnosis and problems 


Provide forms for documenting nursing aims 
Provide forms for documenting nursing tasks 


Execution of nursing Provide forms for documenting performed tasks 
procedures Provide forms for documenting the outcome of nursing tasks 
Coding of diagnoses and Provide catalogs and other means for coding of nursing 
procedures diagnosis 
Provide catalogs and other means for coding of nursing 
procedures 


Nursing discharge and nursing | Provide forms for writing the nursing discharge summary 
discharge summary writing Provide means for finalizing nursing documentation 
Communicate discharge information 


Human resources management | Provide means for managing ward staff 
Provide means for creating a roster 
Assign nurses to patients or rooms 


3.4 Logical Tool Layer: Types of Application Systems in Health care Facilities 89 


The NMDS must support the documentation of all steps of the nursing process. 
To support nursing care planning, the definition and use of predefined nursing care 
plans (comprising recent problems of the patient, nursing goals, and planned nurs- 
ing tasks) is helpful. 

The NMDS offers support for using predefined nursing terminologies and nurs- 
ing classification such as NANDA, NIC, and NOC.” 


3.4.4 Computerized Provider Order Entry Systems (CPOE) 


The care of patients is a highly collaborative process. Not only are different facili- 
ties involved, but many service units as well as different health care professionals 
with different tasks are also involved within the facilities. The interaction of these 
units and people is handled by orders that one unit directs to another unit. This is 
summarized in the function order entry. Order entry can comprise both ordering of 
diagnostic or therapeutic procedures and ordering of drugs. 

Application systems designed to especially support the function order entry and 
to provide the features in Table 3.4 are referred to as computerized provider order 
entry systems (CPOE) or sometimes computerized physician order entry systems. 
CPOE systems support formulation of the order, appointment scheduling, printing 
of labels, and the communication of the order to the service unit. 

When ordering drugs, physicians may choose the most appropriate drug or 
generic drug from drug catalogs. The CPOE system may then also offer decision 
support functionalities such as dosage calculation, drug—drug interaction checks, 
drug allergy checks, or drug lab checks to prevent prescription errors. 

When ordering diagnostic or therapeutic procedures, the results (e.g., lab values 
or X-ray report) must then be communicated back to the ordering facility. CPOE 
systems offer service catalogs that present the available service types of the different 
service units (e.g., laboratory, radiology, surgery). Order sets that describe a typical 
set of combined orders (e.g., a combination of diagnostic procedures that have to be 
performed in a given situation) can support the ordering process; they are activated 
and modified by the ordering clinician. Some CPOE systems support receiving and 
presenting findings. However, this is usually done by other application components 
such as the radiology information system (RIS) or laboratory information sys- 
tem (LIS). 


? NANDA = North American Nursing Diagnosis Association (the abbreviation is often used syn- 
onymously for the international classification of nursing diagnoses), NIC=Nursing Interventions 
Classification, NOC=Nursing Outcomes Classification. 
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Table 3.4 Set of functions and related features typically to be supported by computerized provider 
order entry systems 


Function (from Sect. 3.3.2) | Typical features 


Order entry Provide orders for patient-related drugs 

Provide drug catalogs 

Provide means for minimizing adverse drug events 

| Calculate dosage of drugs 

Provide orders for patient-related examinations 

| Select orders from order sets 

Provide means for scheduling a patient’s appointment 


| View patient-related appointments 


3.4.5 Radiology Information Systems (RIS) 


Facilities that handle the execution of radiological examinations exist as depart- 
ments of hospitals, for example. There, they execute radiological examinations pri- 
marily on the inpatients of the respective hospital. Such facilities may also be legally 
and economically independent facilities, however, which then typically serve the 
care of outpatients, for example, from medical offices. 

When radiological examinations are needed, wards or medical offices order 
them and schedule an appointment. In the case of outpatient care, however, the 
patients often have to perform the function arrange appointments themselves. 
The examinations may then be done using imaging devices, for example for com- 
puted tomography, magnetic resonance imaging, ultrasonography, or digital radi- 
ography. The imaging devices are called modalities. Based on the generated 
images, a specialist in radiology creates a report, which is then sent and presented 
(often together with selected pictures) to the ordering physician. The related 
functions are summarized in Table 3.5.Application systems designed to espe- 
cially support the functions and to provide the features shown in Table 3.5 are 
usually called radiology information systems (RIS). Please note that according to 
our definition, these application systems are not information systems, even if the 
name suggests that they are. 

The RIS offers some features which are also provided by the patient administra- 
tion system (3.4.1), i.e., features for registering patients, appointment scheduling, 
organization of examinations and staff (workflow management), provision of patient 
data and examination parameters, creation of radiology reports, documentation and 
coding of activities, and statistics. A special feature is the close connection to the 
modalities: The R/S typically provides a working list (i.e., patient name and 
requested examination) for the modalities and receives confirmation on the comple- 
tion of a radiologic examination from the modalities. Due to these special features, 
software for RIS typically comes from specialized vendors. 
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Table 3.5 Set of functions and related features typically to be supported by radiology 
information systems 


Function (from Sect. 3.3.2) Typical features 
Execution of radiological Receive orders 
examinations Assign orders to modalities 
Provide forms for writing a report 
Medical admission Provide means for check-in of patient 
Appointment scheduling Assign patients to modalities 
Offer free appointments to health care professionals and 
patients 
Coding of diagnoses and Provide catalogs and other means for coding radiological 
procedures diagnoses 
Provide catalogs and other means for coding radiological 
procedures 
Management of medical devices Manage modalities 
Scheduling and resource Provide means for preparing work schedules 
allocation 


3.4.6 Picture Archiving and Communication Systems (PACS) 


Even if radiologists occasionally still produce images on film, the modalities gener- 
ally produce digital images. Digital images are stored in picture archiving and com- 
munication systems (PACS). These application components allow the storage, 
retrieval, management, manipulation, and presentation of large amounts of image 
data and their quick communication from the storage medium to the attached radi- 
ologists’ workstations. Image data can also be sent from the PACS to the ordering 
departments or facilities in a teleradiology network, for example. Quick communi- 
cation may require a prefetching strategy to retrieve image data from slower storage 
devices and to provide it to faster devices well in advance to the situation in which 
they will be needed. 

Application software products for PACS also comprise means for image process- 
ing and 3D reconstruction. They are often offered by vendors, which also offer 
physical data processing systems such as storage, networks, and modalities. 

Alternatively, vendor-neutral archives (VNAs, Sect. 3.9.3) can be used to store 
image data and other patient-related documents. VNAs are connected to the RZS, the 
image processing components of the PACS, and other application systems using 
communication standards (especially DICOM). The use of the communication stan- 
dards here follows the rules provided in the Integrating the Health care Enterprise 
(IHE) profiles for sharing documents (Sects. 3.7.2.4 and 3.7.2.6). 

Obviously, RIS and PACS in one health care facility should be closely connected. 
They should also have a tight connection to the facility’s patient administration 
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Table 3.6 Set of functions and related features typically to be supported by picture archiving and 
communication systems 


Function (from Sect. 3.3.2) | Typical features 
Execution of radiological examinations | Retrieve pictures 
Display pictures 


| Modify presentation of pictures 

“Hang” pictures like in the analog world 
| Communicate pictures 

Archive pictures 
| Search for old pictures 


system, MDMS, CPOE system, and the patient data management system (PDMS) in 
order to allow quick access to reports and imaging pictures from every unit. 

Table 3.6 sums up the functions being supported and the features usually offered 
for these functions. 


3.4.7 Laboratory Information Systems (LIS) 


Similar to radiology departments, laboratories exist both as functional areas within 
a facility, for example, a hospital, and as independent enterprises that offer their 
services to other health care facilities. Laboratories perform execution of lab exami- 
nations (Table 3.7). During execution of lab examinations, specimens of patients 
(e.g., blood sample, tissue sample) are used. In contrast to radiology departments, 
no appointment scheduling is required in laboratories. Depending on the type of 
laboratory, different examination technologies are used (e.g., chemical analysis of 
blood samples, microscopical analysis of tissue samples). Chemical analysis is usu- 
ally done using automated equipment. Depending on the order, the sample is usu- 
ally distributed automatically to various analytical devices, which are regularly 
checked for their precision in order to conform to quality management require- 
ments. In addition, the laboratory physician checks all results of a sample for plau- 
sibility (so-called validation). 

Application systems supporting execution of lab examinations and offering fea- 
tures as in Table 3.7 are called laboratory information systems (LIS). 

Laboratory information systems support the management of the whole analysis 
procedure: receipt of the order and sample, distribution of the sample and order to 
the different analytical devices, collection of the results, technical and clinical vali- 
dation of results, communication of the findings back to the ordering department or 
facility, and general quality management procedures. The validation of laboratory 
results is more effective when patient-related clinical data (e.g., recent diagnoses, 
drug medication) are accessible to the laboratory physician. The L/S in a particular 
health care facility should therefore be closely connected to the facility’s MDMS, 
patient administration system, CPOE system, and PDMS. Application software 
products for LIS are usually also sold by specialized vendors. 
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Table 3.7 Set of functions and related features typically to be supported by laboratory 


information systems 


“Function (from Sect. 3.3.2) 


Execution of lab examinations 


Typical features 


Receive orders 

Receive blood samples 

Assign order and blood samples to devices 
Collect results from devices 

Display earlier lab results of a patient 
Validate results 

Prepare report 

Communicate report to ordering unit 
Provide means for preparing statistics 


Table 3.8 Set of functions and related features typically to be supported by operation 


management systems 


Function (from Sect. 3.3.2) 


Medical admission 


Typical features 


Provide means for check-in of patient 
Provide forms for documenting medical history 
Provide forms for documenting diagnosis 


Decision-making and patient 
information 


Provide forms for documenting patients’ informed consent 


Execution of operations 


Display vital parameters from monitoring devices 
Provide forms for documenting procedures and outcomes 


Coding of diagnoses and 
procedures 


Provide catalogs and other means for coding diagnoses 
Provide catalogs and other means for coding procedures 
Provide means for creating statistics 


Patient discharge and transfer 
to other facilities 


Provide forms for preparing operation reports 
Provide means for ordering patient transfer to ward 


Supply and disposal 
management, scheduling, and 
resource allocation 


Provide means for managing rooms 

Provide means for managing appointments 

Provide means for managing medical devices 

Provide means for ordering drugs, materials, and laundry 
Provide means for creating operation plans (daily, weekly) 
Provide means for preparing work schedules 


3.4.8 Operation Management Systems (OMS) 


Invasive procedures for patients at a particular health care facility are performed in 
the operating rooms (ORs) at this facility. Usually, patients stay in the OR for only 
a few hours. During this time, they are prepared for the operation, the operation is 
performed, and finally, for a period of time after the operation, the patients’ state is 
monitored. This results in performing the functions listed in Table 3.8. 

Application systems supporting functions and offering features as in Table 3.8 
are called operation management systems (OMS). 

Operation management systems support execution of operations as a specializa- 
tion of execution of diagnostic and therapeutic procedures. They allow operation 
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date and time to be assigned and should therefore be available on the wards as well 
as in the offices and management units of the OR. Depending on the planned opera- 
tions, an operation plan can be created for a day or a week. The data necessary for 
efficient planning are the diagnoses of the patient, the planned operation (medical 
procedure), the surgeons and other staff involved (human resources), the planned 
time for operation (appointment), and the available OR (space). Therefore, the OMS 
should be closely connected to the MDMS. 

A vast amount of data must be documented during each operation, including the 
members of the operating team, the operative procedure, the date and time, duration 
of the operation, materials (e.g., implants) used, and other necessary data to describe 
the operation and its results. Surgeons cooperate tightly with anesthesiologists dur- 
ing the operation. For their documentation, anesthesiologists need a lot of data, 
which must usually be documented by surgeons and vice versa. To avoid transcrip- 
tions, an OMS should therefore also provide supportive features for anesthesiolo- 
gists in an integrated way. 

Usually, the planning data are taken from the operation planning component to 
be updated and completed during and after the operation. These data can be used to 
create an operation report, which may be completed with further comments by the 
surgeons. Therefore, word processing capability is needed. Operation data needed 
for billing must be coded and then communicated to the administrative application 
components. The OMS should also allow extensive data analysis (e.g., operation 
lists for junior surgeons). 


3.4.9 Patient Data Management Systems (PDMS) 


Patients in critical situations are treated in intensive care units (ICU). These patients 
are generally in an unstable state and within seconds may enter into a life- 
endangering situation. Thus, the detailed and complete presentation of all vital 
parameters (e.g., blood pressure, pulse, breathing frequency) is required for a suc- 
cessful therapy. This is only possible when automated monitoring devices continu- 
ously measure and record various parameters. In addition, parameters that could 
point to the initial deterioration of the patient’s status should be automatically 
detected and should lead to an immediate alert of the treating health care profession- 
als. Functions being performed in ICU are outlined in Table 3.9. 

Application systems supporting functions and offering features as in Table 3.9 
are called patient data management systems (PDMS). 

Patient data management systems are specialized to automatically monitor, store, 
and clearly present a vast amount of patient-related clinical data in ICUs. They also 
support scoring (e.g., TISS, SAPS*) and may offer features for decision support 
and various statistical analyses. 


° Therapeutic Intervention Scoring System. 
“Simplified Acute Physiology Score. 
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Table 3.9 Set of functions and related features typically to be supported by patient data 


management systems 


Function (from Sect. 3.3.2) 


Medical admission 


Typical features 


Provide means for check-in of patient 
Provide forms for documenting medical history 
Provide forms for documenting diagnosis 


Medical and nursing care 
planning 


Provide means for preparing a care plan 
Offer decision support for care planning 


Execution of diagnostic, 
therapeutic, and nursing 
procedures 


Display vital parameters from monitoring devices 


Display warning messages 

Provide forms for documenting clinical procedures 
Provide forms for documenting medications 
Create work list for a group of patients 

Print forms 

Provide means for creating statistics 


Coding of diagnoses and 
procedures 


Scoring of the patient (e.g., TISS, SAPSID) 
Provide catalogs and other means for coding of procedures 
Provide catalogs and other means for coding of diagnoses 


Patient discharge and 
transfer to other facilities 


Provide forms for writing a transfer letter or discharge summary 
Provide means for finalizing documentation 

Communicate discharge information 

Provide means for ordering patient transfer to other units 


Supply and disposal 
management, scheduling, 
and resource allocation 


Assign staff to patients or rooms 

Provide means for ordering consumables 
Provide means for ordering drugs 

Provide means for ordering laundry 

Provide means for managing medical devices 
Organize patient transport 

Work scheduling 


After transfer to a regular ward, a short summary of therapies on the ICU should 


be created and communicated to the application components used at the ward. In 
addition, a connection to the application components for order entry and result 
reporting is necessary. Software for a PDMS is sold both by specialized vendors and 
by vendors that also offer automated monitoring tools. 

Intensive monitoring is also required during anesthesia. Therefore, PDMS are 
also used in the preparation, execution, and follow-up of operations. PDMS for 
anesthesia have additional features for anesthesia planning and execution. 


3.4.10 Enterprise Resource Planning Systems (ERPS) 


As part of the administration of health care facilities, there are functions to be per- 
formed that differ little from those in facilities in other industries. These include, in 
particular, the functions controlling, financial accounting, facility management, 


human resources management, quality management, and supply and disposal man- 
agement (Table 3.10). 
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Table 3.10 Set of functions and related features typically to be supported by enterprise resource 
planning systems 


“Function (from Sect. 
2) Typical features 


Controlling Provide means for overhead cost management 
Provide means for product costing 

Provide means for cost center accounting 
Provide means for cost element accounting 
Financial accounting Provide means for accounts payable 

Provide means for accounts receivable 
Provide means for general ledger accounting 
Provide means for asset accounting 


Facility management Provide means for preventive maintenance 
Provide means for control of security issues 
Provide means for incident tracking 


Human resources Provide means for organizing recruitment 
management Provide means for organizing training 
Provide means for organizing career development 
Provide means for performance evaluation 


Quality management Provide a collection of internal processes and regulations 
Provide means for editing and graphically illustrating collections of 
internal processes and regulations 


Supply and disposal Provide means for managing logistics 

management Provide means for stock-keeping 

Provide means for order management 

Provide means for managing and monitoring disposal 


Application systems supporting functions and offering features as in Table 3.10 
are called enterprise resource planning systems (ERPS). ERPS enable health care 
facilities to manage their financial, human, and material resources. 

A close connection is needed to the facility’s patient administration system, in 
particular, but also to the other application components mentioned before, in order 
to obtain, for example, billing data and legally required diagnoses and procedure 
codes. Most of the application software products used for ERPS in health care facili- 
ties are not specific to health care but are also used in other industries outside health 
care where similar administrative functions have to be supported. 

One major goal of the ERPS is the documentation and billing of all accountable 
services. The types of data needed and the details of billing depend on the country’s 
health care system. 


3.4.11 Data Warehouse Systems (DWS) 


For decision-making, the management of a health care facility (Table 3.11) requires 
up-to-date information about the facility’s operation as a whole. The management 
is, for example, interested in answers to questions such as: What are the top ten 
diagnoses of the patients treated in our facility? Which department of the facility 
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Table3.11 Setoffunctions and related features typically to be supported by data warehouse systems 


Function (from Sect. 3.3.2) | Typical features 


Management of health care facilities | Integrate data from different application components 
Structure data 
Analyze data 
| Provide means for data mining 


Execution of clinical trials | Provide means for recruiting patients 


causes the highest material costs? In which department do patients stay longest on 
average? 

In order not to jeopardize the performance of these application systems with 
resource-consuming data analyses, dedicated application systems are used that 
extract the required data from the source application systems at certain intervals and 
then make them available for analysis. Application systems that support functions 
and offer features as in Table 3.11 are called data warehouse systems (DWS). 

Data warehouse systems are also used to support medical research, especially for 
clinical trials. Loading data, for example from the MDMS, LIS, RIS, or CPOE sys- 
tem into a DWS, the recruitment of patients for clinical trials, and the statistical 
evaluation of patient data can be effectively supported. 

Data warehouse systems can help to answer the aforementioned questions by 
pooling management-relevant data from other systems such as the ERPS and the 
CPOE system and providing means to analyze these data through data mining tech- 
niques. A DWS supporting management of health care facilities is often called a 
business intelligence system. 

Extracted data in the DWS have been transferred and aggregated into a suitable 
format and then actively loaded into the data warehouse (push principle). A specific 
request on the data will only access data already loaded into the data warehouse. 

An ISO standard exists which provides implementation guidance for data ware- 
houses in health information systems [6]. 


3.4.12 Document Archiving Systems (DAS) 


As part of the function archiving of patient information, long-term archiving is a 
particular challenge for both paper-based and digital documents. Application sys- 
tems supporting this function and offering the features listed in Table 3.12 are called 
document archiving systems (DAS). 

Dependent upon the type of data and national laws, patient-related data must be 
stored for up to 30 years. For long-term archiving, confidentiality, availability, and 
integrity of the data according to the Open Archival Information System model 
(ISO 14721) must be guaranteed. Availability means that data must be retrievable 
and readable at any time throughout the archiving period. To ensure integrity, data 
must be complete and unchanged. In health care, authenticity of the author and the 
time of the creation of a document are important aspects of integrity. For example, 
unauthorized alteration of the date of creation results in the loss of integrity of 
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Table 3.12 Set of functions and related features typically to be supported by document 
archiving system 


Function (from Sect. 3.3.2) ~ | Typical features 


Long-term archiving Import documents 
Scan documents 
Index document content 
Manage storage formats 
Manage storage media 
Provide access to archived information 
Attach digital signatures 
| Communicate documents to other applications 


archived data. The conditions of confidentiality, availability, and integrity can hardly 
be met by the individual application systems introduced before. This is especially 
true as these application systems cannot be expected to be in use for up to 30 years. 
It therefore makes sense to assign this task to a dedicated application system and 
copy the documents to be archived there. 

Document archiving systems offer long-term archiving of patient-related and 
perhaps of other data and documents. Archiving is based on sustainable standard- 
ized data formats, document formats, and interfaces. The DAS also provides stan- 
dardized indexing of document content and regular updates of storage media. 
Qualified electronic signatures, for example in compliance with European directive 
1999/93/EC [7], can be used to guarantee long-term integrity of stored data in case 
the DAS is enabled to renew outdated signatures and hash algorithms. DAS are typi- 
cally closely linked to all application systems that generate data and documents 
which it must store for a long time. It obtains copies of data and documents from 
those systems, indexes them, and stores them, while enabling fast retrieval. Paper- 
based documents can be integrated through scanning, which makes it possible to 
eliminate the physical space needed for paper-based archiving. DAS can typically 
archive not only text-related documents but also images, videos, and other multime- 
dia data. All these documents may be stored using established non-proprietary 
industry standards such as: 


e ASCII (American Standard Code for Information Interchange), 

e PDF/A, an ISO standard for long-term archiving of documents based on the 
Portable Document Format (PDF), 

e XML (Extensible Markup Language), 

e TIFF (Tagged Image File Format), 

e JPEG and MPEG, acronyms for the names of the committees that created the 
standards (Joint Photographic Experts Group and Moving Pictures Expert Group), 

e Digital Imaging and Communications in Medicine (DICOM, Sect. 3.7.2.4), 

e CDA (Clinical Document Architecture), an ANSI standard for the structuring of 
clinical documents (Sect. 3.7.2.2). 


It makes sense to use vendor-neutral archives (Sect. 3.9.3) to realize DAS. 
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Patient-related medical data and documents stored in the DAS in a facility have 
to be made available to the medical management documentation system of this 
facility in order to enable their users to directly access information from earlier 
patient contacts. 


3.4.13 Application Systems for Patients 
and Informal Caregivers 


In contrast to the previously described application systems in health care facilities, 
application systems for patients and informal caregivers cannot be structured that 
clearly by the tasks they perform and their typical functionalities. This is due to the fact 
that there are a multitude of mobile health (mHealth apps), desktop, and browser appli- 
cations available that support patients in better understanding, dealing with, and (inde- 
pendently) managing their health condition. In addition to application systems dealing 
solely with self-diagnosis, self-treatment, or knowledge management, there are also a 
number of combined application systems, i.e., mHealth apps, that provide knowledge, 
support therapy, and assist patients in keeping their appointments at the same time. 
Some typical types of application system for patients and informal caregivers are 
described below. These are examples and by no means represent an exhaustive list. 


3.4.13.1 Patient Portals 


Patient portals are offered by health care facilities. They are primarily available for 
patients of this facility and informal cargivers to provide them with an overview of their 
health data, organize documents, and actively manage themselves. Patient portals can 
also be used to improve communication between health care professionals and patients. 
For example, relevant documents can be uploaded to the portal by patients before 
admission to a hospital or rehabilitation center and are made available there for early 
access. This improves not only the preparation for admission to a facility but also cre- 
ates transparency of information, which is crucial for patient empowerment. 

Patient portals support medical knowledge management including document 
management and, in some cases, also appointment scheduling. Thereby, they offer 
features such as those described in Table 3.13. 

In addition to patient portals that focus exclusively on the needs of patients, there 
are also special portals for relatives. Such portals mostly support relatives in their 
role as informal caregivers. Simple portals for relatives usually provide information 
about a disease and how to deal with it. They are therefore also referred to as infor- 
mation platforms. Information can be provided in different ways, ranging from 
simple structured information sets to comprehensive e-learning services. More 
comprehensive portals for relatives also offer opportunities for medical knowledge 
management as previously described for patient portals. 
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Table 3.13 Set of functions and related features typically to be supported by patient portals 


Function (from Sect. 3.3.1) Typical features 
Medical knowledge management Administer user account 
including document management Provide/upload documents 


Retrieve documents 
Fill in forms 

View treatment 
Information retrieval 


Appointment scheduling | Manage appointments (view, edit, and schedule) 


3.4.13.2 Telemonitoring Systems 


Telemonitoring systems are provided by health care facilities or by health insur- 
ance companies. They are primarily used to monitor patients’ state of health 
remotely, reinforcing a patient-centered health care approach. The aim is to 
detect critical or conspicuous changes in the state of health in order to be able 
to address them as quickly as possible. Therefore, they are used particularly 
frequently in post-acute monitoring of patients, for example, after discharge 
from a hospital or a rehabilitation center, as well as in chronic diseases, such as 
with Mr. Russo’s heart failure. 

In principle, telemonitoring systems acquire a patient’s health data, transmit it to 
a health care professional, and represent it to that professional (and in some cases 
also to the patient) in an appropriate form. The monitoring of the health status can 
be done either in real time or time-delayed. In addition to a clear visualization of the 
recorded data and its provision to a treating health care professional, some telemoni- 
toring systems also handle the partial or complete analysis of the data. Health care 
professionals either receive aggregated information on a patient’s health status or 
receive alerts as soon as a critical value or abnormal changes in health status are 
detected. 

Telemonitoring systems thus support the patient’s self-management abilities and 
self-diagnostics through continuous monitoring. Thereby, they offer features such 
as those described in Table 3.14. 

The range of functions and complexity of telemonitoring systems varies greatly 
in practice. For example, simple telemonitoring systems only record a patient’s state 
of health via manual data entries by patients, for example, by querying the symp- 
toms associated with a disease. There are also a number of telemonitoring systems 
that, in conjunction with other systems such as a blood pressure monitor, can also 
record vital parameters and evaluate them independently in combination with other 
patient-related data. The range of functions thus extends from simple observations 
to comprehensive application systems which, in addition to recording, also perform 
analysis, management, and initial diagnosis. 

Telemonitoring systems are increasingly supplemented by functionalities for 
patient education and patient coaching. 
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3.4.13.3 Self-Diagnosis Systems 


Simple self-diagnosis systems in the form of web applications or mHealth apps 
are used to provide people suffering from ailments with information about what 
illness they might have. The so-called symptom checker systems provide possi- 
ble diagnoses or disease information matching the symptoms entered by the 
patient in just a few minutes. This works particularly well for simple, common 
diseases. For rarer, more complex conditions, however, the results provided are 
significantly less precise. 

Self-diagnosis systems are also used in various disciplines for remote diagnosis, 
for example, when a patient is unable to visit a physician. In this case, self-diagnosis 
systems are considered telemedicine applications that are used for communication 
between physicians and patients. 

Self-diagnostic systems support self-diagnostics and self-management of 
patients. Thereby, they offer features such as those described in Table 3.15. 

Self-diagnosis systems usually operate on the basis of artificial intelligence and 
neural networks. They automatically analyze a patient’s entries, from simple texts 
to image data. As mentioned before, some of these application systems transmit 
their results automatically or at the request of a patient to a (specialist) physician in 
the sense of telemedicine. Such self-diagnosis systems are used, among other things, 
in dermatology for the prevention and early detection of skin diseases such as 
skin cancer. 


Table 3.14 Set of functions and related features typically to be supported by telemonitoring systems 


Function (from Sect. 3.3.1) | Typical features 


Self-diagnostics Recording/measurement (e.g., vital parameters and symptoms) 
Monitoring of vital parameters 

Analysis 

Reporting 

Diagnosis/detection of risks 

Visualization 

Sending alarms 


Table 3.15 Set of functions and related features typically to be supported by self-diagnosis systems 


Function (from Sect. 
24.1) Typical features 


L 


Self-diagnostics Analysis (e.g., image analysis, analysis of medical/therapeutic 
parameters, and text analysis) 

Provision and evaluation of assessments/tests 

Diagnosis 

Reporting 

Information provision/provision of information 

Patient education 
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It is important to note that no form of self-diagnosis systems can replace profes- 
sional assessments by physicians, not to mention professional treatment. Instead, the 
aim is to involve patients to a greater extent in the care process (patient empowerment) 
and to improve communication between patients and health care professionals. 


3.4.13.4 Self-Treatment Systems 


Self-treatment systems range from simple treatment-assisting systems to strengthen 
patients’ self-management skills to individual therapy systems that can be used 
either as a complement or as an alternative to standard therapy. In addition to 
software-based mHealth apps, desktop and web applications, more and more 
hardware-based systems are also being used. Through the implementation of differ- 
ent sensor technologies, these enable not only the guidance of therapies, but also a 
monitoring of the state of health or even an evaluation of therapeutic measures. 

Overall, the feature set of self-treatment systems varies greatly and depends, 
among other things, on the intended use and the specific area of application. 
Table 3.16 shows some typical features to support patient self-treatment. 

Information-only application systems represent the simplest form of self- 
treatment systems. These simply contain descriptions to educate patients about one 
or more alternative therapies. For example, Mr. Russo can access information about 
a healthy diet for lifestyle changes or learn about ways to reduce stress, such as yoga 
exercises. More sophisticated self-treatment systems include not only information 
and guidance but also concrete instructions on how to perform a therapeutic or 
complementary measure. For example, Mr. Russo is not only recommended certain 
yoga exercises, but they are also explained in detail, for example, in the form of 
texts or instructional videos. Thereby, Mr. Russo can exercise along with the appli- 
cation system and mark off individual workouts to save his progress. Embedded 
assessments, whether automated based on sensor technology or as queries via man- 
ual data entry, also help to record the current state of health and changes caused 
during the therapy period. These can either be feedback to the patient or be for- 
warded in the form of telemedicine applications to a health care professional for 
further interpretation and subsequent therapy adjustment. 

Reminders to perform an activity, such as exercise sessions or taking medication, 
are also integral parts of self-treatment systems. 


Table 3.16 Set of functions and related features typically to be supported by self-treatment systems 


Function (from Sect. 3.31) E | Typical features 


Self-treatment Therapy (instruction, evaluation, adaptation) 
Monitoring 
Provision and evaluation of assessments/tests 
Reporting 
Information provision/provision of information 
Reminder (e.g., for taking medication) 

Serious games 
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3.4.14 Other Application Systems 


In addition to the application systems introduced so far, we can usually find many 
other types of application systems, often serving specific needs of the respective 
health care facility and its departments. For example, depending on the size of the 
hospital, a hospital may have its own pharmacy department which needs a phar- 
macy information system to supply wards and patients with the right drugs in the 
right dose. Depending on the specializations of a hospital, there may be, for exam- 
ple, a cardiovascular information system (CVIS) or a dialysis information system, 
which are specialized MDMS. 

Table 3.17 lists some of these specific application components. This list is not 
intended to be exhaustive, however. 

Until now, we have focused on “classical” application systems, i.e., software 
installations in health information systems primarily supporting the functions as 
listed in Sect. 3.3. But there is an increasing number of installations of software in 
health care settings that primarily control medical devices. Hence, medical devices 
can increasingly be considered to be application systems and in many cases to be 
specialized MDMS. Consequently, they not only provide information (e.g., findings 
and images) via respective interfaces, but also need information from other applica- 
tion components (e.g., patient, case, order). This close interconnection is often 
referred to by the term “converging technologies.” Due to the considerable risks for 
patient safety, reasonable diligence must be exercised when integrating these con- 
verging technologies into the computer-based part of health information systems. 


Table 3.17 Further specific application components in health information systems (examples) 


Application component | Description 


Blood bank management | Support blood donor services, blood analyses, administration of 
_systems blood bottles 


Cardiovascular Provide many features of clinical information systems (CIS) and 
information systems radiology information systems (RIS) while tailoring the special needs 
(CVIS) of cardiology departments 

dialysis information Provide many features of CIS while tailoring the special needs of 
systems dialysis departments; have interfaces to hemodialysis machines 
Oncology information Provide many features of CIS while tailoring the special needs of 
systems oncology departments 


Orthopedics information | Provide many features of CIS while tailoring the special needs of 
systems orthopedics departments; can include a computer-aided design 
(CAD) system for transplant planning 


Pathology information Have similar features as L/S, for example, receiving orders, writing 
systems reports 


Pharmacy information Support the workflow in pharmacy departments: receiving drug 

systems orders, managing the drug stock, distributing drugs throughout the 
hospital 

Teleradiology systems Enable evaluations of radiological images from (external) 


radiologists’ remote workplaces and may be closely connected to RIS 
and PACS 
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3.4.15 Clinical Information Systems (CIS) and Electronic 
Health Record Systems (EHRS) as Composite 
Application Systems 


Not every health information system contains an MDMS, an NMDS, or a CPOE 
system as separate, identifiable application systems. Instead, these components are 
often closely integrated modules of the so-called clinical information systems (CIS). 

Clinical information systems are also often called electronic health record sys- 
tems (EHRS or EHR systems). As introduced in Sect. 2.10, the electronic health 
record (EHR) is a complete or partial health record stored on an electronic storage 
medium. Given this definition, every computer-based application component sup- 
porting the execution of diagnostic and therapeutic procedures or other subfunc- 
tions of patient care (e.g., MDMS, outpatient management system, NUDS, PDMS) 
contains at least a partial EHR. In the CIS of a certain health care facility, these 
partial EHRs are often integrated and made available to the professionals from all 
areas of the facility to provide one harmonized view on the data of a patient. Because 
of this harmonized view, the term electronic health record system (EHRS) as a par- 
ticular application component has become quite common. 


3.5 Logical Tool Layer: Data Integrity 


In the previous section, we saw that there can be very many different types of appli- 
cation systems in health information systems. Therefore, we are dealing with very 
complex information systems in health care. In information systems, it is generally 
important to make sure that the data stored is correct. In complex health care infor- 
mation systems, this is a particular challenge. 

For the correctness of data in health information systems, we use the term data 
integrity. There are many aspects of data integrity. Here we want to focus on the 
following aspects: 


e the unique and correct identification of objects (object identity), 

e the correct representation of relationships between these entities (referential 
integrity), 

e the consistency of duplicated data among all application components in a health 
information system (data consistency). 


In this section, you will learn more about these aspects of data integrity. 

Object identity originates from object-oriented programming and means that an 
object has an existence that is independent of its value. Thus, two objects may look 
the same, i.e., they have the same value, but can still be different. Applying this to 
the representation of entity types in a database leads to the requirement that the 
representation of every entity must be uniquely identifiable. In a health informa- 
tion system, this is especially important for entity types such as “patient” and 
“case,” but also for “finding,” “order,” and all other entity types (Sect. 3.2.3). This 
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identity is needed, since all data need to be assigned to a specific patient and their 
cases. For example, if application components exchange information on the patient 
entity “Mr. Russo,” they must be sure they are communicating about the same 
entity (the “real” Mr. Jakub Russo, not another patient who has by chance the 
same name). 

Experience has shown that object identity of the entity type “patient” can be 
guaranteed only when every patient receives a unique number, the PIN. The PIN 
should have no internal meaning. That is, it is created continuously and is usually 
numerical. Past attempts to generate a PIN from data collected from the patient, for 
example, from the date of birth and the name, have led to considerable problems, for 
example when a date of birth is corrected and thus the PIN also changes. In this 
case, object identity could be compromised. For example, the “real” Mr. Jakub 
Russo has the PIN 3050.1515 that is used throughout all application components 
and in the communication between them when referring to this real person. 

Similar actions should be taken for the entity type “case.” A CIN, which should 
also have no apparent meaning, should be assigned for every case. If all application 
components of a health information system ensure that a case identified with a CIN 
is always assigned to the correct patient, the CIN can be used as an identifier for the 
patient. During order entry, for example, the CIN can then be used to uniquely iden- 
tify a patient when ordering a laboratory test. 

In every health care facility, assigning a PIN and a CIN to a patient is part of the 
function patient identification of this patient, a subfunction of patient admission. 
The PIN must be used in all parts of the hospital, and thus in all application compo- 
nents, for the identification of the patient and will also be used during future visits. 
Since PIN and CIN are assigned during patient admission, only one admission has 
to be performed and only one PIN has to be assigned to patients during their visit, 
regardless of which ward they are treated on. For example, Mr. Russo was assigned 
a PIN (and CIN) when he was first admitted to Ploetzberg Hospital. This PIN will 
now be used whenever Mr. Russo is admitted to this hospital again. 

This works well if there is exactly one dedicated application system supporting 
patient admission, namely the patient administration system. The patient adminis- 
tration system must have direct access to a database that holds data allowing the 
reidentification of all past patients and cases in the hospital. To have this MPI as part 
of the patient administration system is an obvious choice. 

MPI are also required for patient identification in HIS which cover more than 
one health care facility. In tHIS, data about a patient are to be used across different 
facilities, for example, when exchanging data between two hospitals or between a 
hospital and a nursing home. MPI as a dedicated application system provides a 
unique transinstitutional identification of a patient across separate patient adminis- 
tration systems. This transinstitutional PIN is cross-mapped by the MPI to the PINs 
of the respective health care facilities. 

Object identity provides a unique identification for entities. Referential integrity 
builds on top of this and means the correct assignment of entities to each other. For 
example, a number of cases must be correctly assigned to a certain patient, or labo- 
ratory findings must be assigned to a given case. Object identity is the precondition 
for referential integrity. 
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Object identity for patients and cases needs to be achieved among all application 
components, regardless of whether they are computer-based or not. Without object 
identity, there is no referential integrity, and without referential integrity, results 
cannot be related back to the correct patient. Therefore, without the correct usage of 
the PIN and CIN, the pure installation of technical means such as communication 
networks and computer systems is practically useless, as the precondition for data 
integrity is not met. 

Object integrity and referential integrity form two elements of data integrity. The 
third element we want to look at is data consistency. Data consistency means that 
copies of data on the same entity are identical. 

In health information systems architectures with many different application sys- 
tems, the application systems often use the same data on patients and thus store 
them redundantly in their own database systems. This means that there are copies of 
data (e.g., of patient name, patient diagnosis, laboratory findings) that represent the 
same information about one particular entity. We call these copies of the same data 
“duplicates.” 

Obviously, these duplicates are supposed to be identical in all application sys- 
tems where they are stored. In this case, we denote these duplicates as consistent. If 
the data are not identical and thus represent contradictory information, we call the 
duplicates inconsistent. Transaction management tries to make sure that data are 
and stay consistent—we then talk of replicates, meaning that copies of data are 
automatically held consistent. In health information systems having only one appli- 
cation system with only one database system, no redundant data exist, as all data are 
the so-called unicums—they only exist once. 


3.6 Logical Tool Layer: Architectural Styles 


As defined in Sect. 2.11, the architecture of an information system describes its 
fundamental organization, represented by its components, their relationships to 
each other and to the environment, and the principles guiding its design and evolu- 
tion. The components of health information systems comprise functions, business 
processes, and tools for data and information processing, especially application 
components. 

With regard to the functions and processes, there are considerable differences 
between information systems of different kinds of health care settings. For example, 
there are very clear differences in functions and processes between hospitals on the 
one hand and patients’ home environments on the other. However, there are very 
great similarities at the domain layer of hospital information systems, as the hospi- 
tals’ goals and thus the hospitals’ functions are in general the same. All functions 
presented in Sect. 3.3 should thus be supported in every hospital information sys- 
tem. Remember that, from our point of view, these functions can be supported by 
non-computer-based or computer-based application components. 
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However, even for the same kind of health care setting, there are usually signifi- 
cant differences in information systems architectures with respect to the types and 
relationships of tools used and the way they are integrated. We will introduce a 
multidimensional taxonomy, which can be used to characterize different styles of 
architectures. This taxonomy will help to describe real health information system 
architectures, to compare them, and to assess them. 

We will first take a look at the logical tool layer and later (in Sect. 3.10.3) look at 
health information systems’ architectural styles at the physical tool layer. In doing 
so, we concentrate on the computer-based part of health information systems. 

Architectural styles at the logical tool layer of the computer-based part of health 
information systems are characterized by the 


e number of databases being used to store data (especially patient-related data), 

e number of application systems used to support the functions, 

e number of different application software products used to install the application 
components and the number of vendors of these products, and 

e patterns of communication links between the application components used. 


These facets will be introduced as semantic dimensions which can be used to 
categorize hospital information systems’ architectures. 


3.6.1 Number of Databases: Central vs. Distributed 


Application systems of health information systems may store data on certain entity 
types persistently. Usually, a database is used for this purpose. We will use the num- 
ber of databases storing data in health information systems as the basis to distin- 
guish possible data distribution styles at the logical tool layer of health information 
systems: the DB! and the DB" style. 


3.6.1.1 DB! Architecture 


If a health information system (or its sub-information system) comprises only one 
database to store all patient-related data, we call this a DB! architecture (Fig. 3.24). 
This single database system is often called the central database system for this 
(sub-)information system. 

The precondition for the DB’ architecture (also: central architecture) is that all 
application systems store their data only in the central database and that this data- 
base is open for accessing and storing data there. There are two ways for realizing 
this style: 


e The application software products of the application systems originate from the 
same vendor who designed the database, they are all self-developed by a health 
care facility, or they have been developed particularly for this health care facility. 
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e There exists an appropriate API along with standards to query and manipulate 
the database. This can be achieved by using an open platform (Sect. 3.9.3) where 
the database schema on the persistence layer does not need to be known. 


If application components from different vendors are used and the previous con- 
ditions are not fulfilled, the so-called DB” style can usually be found. 


3.6.1.2 DB" Architecture 


In health information systems based on commercial software components from several 
different vendors, we can usually find DB" architectures (also: distributed architec- 
ture). This means that several application components store data on certain entity types 
persistently and contain their own database systems. Figure 3.22 presents this style. 

As aconsequence of this style, patient-related data must be stored redundantly in 
different application components. For example, data on the entity types “patient” 
and “case” may be stored in different application components, such as the patient 
administration system, LIS, and RIS. 

In this architecture, great emphasis must therefore be placed on the consistency 
of redundant data (Sect. 3.8.1). For example, the architecture must define which 
system is the responsible source for which data elements. It may be useful to state, 
for example, that data on patient and case may be created and changed only by the 
patient administration system (however, the other components may locally store 
and use a copy of these data). We will discuss these topics in more detail in 
Sect. 3.9.1. 
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Fig. 3.22 DB" style with multiple application systems, each with its own database system, using 
3LGM? symbols. The cloud in the center indicates that some as yet unknown means is needed to 
link the components 
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It is quite obvious that in DB” architectures consistency of redundant data can 
only be achieved if the application systems are able to communicate with one 
another, i.e., they must be interoperable. We will discuss interoperability of applica- 
tion systems in more detail in Sect. 3.7.1. 


3.6.1.3 Mixed DB!/DB® Architectures 


In practice, you will hardly find health information systems with a pure DB! style. 
Even if one central application component with the central database has been 
installed in order to support the functions, it is hardly possible to stop implementa- 
tion of further application components; and those application systems will usually 
come with their own databases. Hence, even if a considerable part of these health 
information systems is DB! styled, they are in sum actually DB" styled. Similarly, 
even DB? styled health information systems contain sub-information systems which 
are DB! styled. 
We will refer to the mixed style by the string “DB!/DB””. 


3.6.2 Number of Application Systems: 
Monolithic vs. Modular 


In the simplest case, the overall health information system consists of only one 
computer-based application system which supports most of the functions. This 
application system would then look like the one rock on which the whole hospital 
rests. Respective health information systems are commonly called monolithic. We 
will refer to this style by the string “AC’”. Of course, this application component 
contains the central database and AC! correlates with DB'. A graphical representa- 
tion of such a (DB!, AC!) architecture is presented in Fig. 3.23. 

Especially in large health care facilities such as university medical centers or 
even in home settings, however, one application component is usually not sufficient 
to support the different functions. This leads to architectures with a multiplicity of 
application components, which can be denoted by AC” and are called modular 
architectures. 


Fig. 3.23 (DB', AC') 
architecture using 3LGM? 


symbols. The rectangle Computer-based application component 
denotes the application 
system that contains a © 


database system (denoted 
by the cylinder) 
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Fig. 3.24 (DB', AC”) architecture with multiple application systems, using 3LGM? symbols. Only 
one application system (in the center) contains a database system 


However, modular architectures can still be DB! architectures: For example, the 
RIS, the LIS, and the patient administration system are connected to a certain appli- 
cation system which shares one single database management (Fig. 3.24). The appli- 
cation system in the middle may be an open platform (Sect. 3.9.3). Such (sub-) 
information systems can be described by (DB!, AC"). 

Anyhow, there is still widespread use of a combination of many application com- 
ponents and many databases, i.e., of (DB", AC") architectures, as in Fig. 3.22. 


3.6.3 Number of Application Software Products and Vendors: 
All-in-One vs. Best-of-Breed 


The terms “homogeneity” and “heterogeneity” are commonly used to describe 
whether a health information system consists of somehow similar components or 
very different ones. A practical measure is the number of application software prod- 
ucts installed or the number of vendors delivering these products to a health infor- 
mation system. We denote a homogeneous architecture, i.e., a (sub-)health 
information system with software from only one vendor, as V’. Consequently, inde- 
pendent of the number of application systems, V'-HIS use only application software 
products that all come from the same vendor. On the contrary, heterogeneous archi- 
tectures comprise software from several vendors and are denoted as V”. 

Obviously, (DB!, V!) architectures are more common than (DB!, V°*) 
architectures. 
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An (AC®, V”) architecture where the different application systems are based on 
software from different vendors is commonly denoted as best-of-breed architecture, 
pointing to the fact that the health care setting combines the “best” application soft- 
ware products from different vendors. This best-of-breed architecture is typically 
DB? although (DB!, V") architectures could become more common in the future. 

On the contrary, a monolithic (AC!, V!) architecture and even an (AC, V!) archi- 
tecture emphasizes that the health care facility selected only application software 
products from exactly one vendor to support as many functions as necessary. This 
homogeneous architecture is also called all-in-one architecture. 


3.6.4 Communication Pattern: Spaghetti vs. Star 


Application systems that are part of an AC” architecture have to be connected as we 
discussed before. One way would be to directly connect those application systems 
that need to exchange certain patient-related data. 

For example, if data on the entity types “patient” and “case” are needed in the 
patient administration system in the RIS and in the LIS, direct communication links 
between these components seem to be a possible solution. Hence, a communication 
link allowing for the transfer of patient data between the patient administration 
system and the RIS may be introduced. Consequently, when connecting several 
application systems, this will lead to an increasing number of bidirectional com- 
munication links. This architecture is called spaghetti style. All these different links 
must be supported and managed. As the number of application systems rises, the 
number of links grows nearly exponentially. The maximum number of communica- 


n-1 

tion links between n application components (n > 2) is $x. We denote architec- 
x=l 

tures with this spaghetti-styled communication pattern as CP”. Figure 3.25 presents 

a (DB’, AC’, V”, CP") architecture. 

To reduce the large number of links, one can use smarter methods and tools to 
organize and implement the interoperability of application systems, for example, by 
installing an application system in the “middle”, ensuring communication between 
the application systems. 

For example, most hospital information systems following the DB" style use a com- 
munication server. By using a communication server, no direct communication links 
between application systems are needed. Links are needed only between the applica- 
tion systems and the communication server. The number of links that must be man- 
aged can consequently be low—ideally, only n links exist for n application systems. 

We call this style star architecture and denote it as CP’. Figure 3.26 presents a 
(DB", AC", V”, CP') architecture. Note that star architectures do not necessarily 
contain communication servers, as the center of the star may also be an application 
system with a central database. Consequently, (DB', AC") architectures will also be 
CP! architectures. Furthermore, we may call a service-oriented architecture (SOA) 
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Fig. 3.25 (DB", AC", V", CP") architecture with multiple application systems, using 3LGM? sym- 
bols, with several bidirectional communication interfaces. This representation is also called a “spa- 
ghetti” architectural style 
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Fig. 3.26 (DB", AC", V”, CP') architecture with multiple application systems connected by a spe- 
cific application component, using 3LGM? symbols. This representation is also called a “star” 
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with one application component serving as a broker or as a service bus a CP! archi- 
tecture as well. But for AC', this concept obviously does not make sense and neither 
CP! nor CP" should be applied. 


3.7 Logical Tool Layer: Interoperability and Standards 


As we saw in the previous section, health information systems are characterized by 
containing many application systems, i.e., they are usually of the AC" architecture 
type. And we saw that they can only guarantee data integrity in their health informa- 
tion systems if the application systems communicate with each other. Even more, 
this communication is the absolute prerequisite for the health information system to 
fulfill its task of ensuring the necessary data and knowledge logistics. 

Thus, application systems need to be able to communicate—they need to be 
interoperable. Without interoperability, no meaningful integration of application 
systems within health information systems is possible. Integration means that the 
application systems are put together in such a way that the resulting information 
system—as opposed to its parts—displays a new quality. There are various kinds 
and aspects of integration, as we will discuss later in Sect. 3.8. 

Interoperability in general is the ability of two application systems to exchange 
information with each other and to use the information that has been exchanged. 
Saying that two application components are interoperable thus indicates that (1) 
they have interfaces and (2) they are—on the most minimal level of interoperabil- 
ity—basically able to send and receive data via these interfaces. 

In this chapter, you will first be given an introduction into various aspects of 
interoperability within health information systems. Costs of the implementation and 
maintenance of health information systems can be significantly reduced when the 
application system’s interfaces are based on standards. In Sect. 3.7.2, we will dis- 
cuss recent interoperability standards and how they support the various aspects of 
interoperability. 


3.7.1 Aspects of Interoperability 


How does communication really work? If two application components want to 
meaningfully communicate, a consensus must exist about four aspects: 


e the technical means of data exchange, 
e the syntax of the exchanged data and messages, 
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Fig. 3.27 Four aspects of 
interoperability describing 
meaningful communication 
between application 
systems. (Adapted 

from [8]) 
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e their semantics (i.e., meaning), 
e the organization of communication with a given process. 


This leads to four aspects of interoperability: technical interoperability, syntactic 
interoperability, semantic interoperability, and process interoperability (Fig. 3.27). 

We will describe interoperability as a property or capability of application sys- 
tems or of application software products used to install application systems. 

Please note that the four aspects of interoperability do not allow dichotomous 
statements about application systems or application software products. Rather, they 
are concepts that can exist to varying degrees and relate to different aspects. For 
example, semantic interoperability may refer to more aspects in one application 
system than in another application system without completely denying semantic 
interoperability in the other application system. 


3.7.1.1 Technical Interoperability 


Technical interoperability, as the most minimal level of interoperability, is the abil- 
ity of an application system to send or receive “bits and bytes” in a reliable and 
standardized way and thus possesses respective interfaces and implements proto- 
cols. The data may be sent or received as a file, string, or continuous stream. Files 
and strings of data can be considered messages (Sect. 2.2). Web technologies such 
as REST application programming interfaces (APIs) provide such technical 
interoperability. 

If the application system wants to send messages to or receive messages from an 
application system installed on a different computer, these computers need to be 
physically interoperable (Sect. 3.10.2) and the interfaces have to be able to interact 
with lower layer communication protocols at the physical tool layer as defined in 
the ISO/OSI reference model (Sect. 3.10.2). 

For example, the patient administration system is technically interoperable if it 
possesses an interface for reliably sending or receiving a message to or from another 
interoperable application system such as the RIS. The message exchange must work 
regardless of whether both application systems are installed on the same or on dif- 
ferent servers. 

To be able to consider the structure, content, or meaning of the exchanged mes- 
sages, higher levels of interoperability are needed. 
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3.7.1.2 Syntactic Interoperability 


An application system is syntactically interoperable if it is technically interoperable 
and additionally uses a predefined structure for the exchanged messages. Thus, 
when technically exchanging a data file, string, or stream, specific data elements can 
be identified, such as beginning and end of a message or of message segments con- 
taining data on certain entity types such as “patient,’ “case,” or “finding.” 
Syntactically interoperable application systems are thus able to obtain information 
from received messages—exchanged data becomes machine-readable. 

A quite simple approach to structure exchanged data are data formats such as 
CSV (comma-separated values) or XML. However, these formats cannot support 
syntactic interoperability by themselves, as they need additional agreements or 
rules, for example, on where to find the patient’s name or birthdate in the given 
dataset. 

Communication standards such as Health Level 7 Version 2 (HL7 V2), DICOM, 
and Health Level 7 Clinical Document Architecture (HL7 CDA) provide a data or 
document format together with clear rules on where to find which data element. 
Thus, they support syntactic interoperability. All these communication standards 
are presented in more detail in the next sections. 

For example, the patient administration system is syntactically interoperable if it 
is technically interoperable and can use HL7 V2, specifically the message type 
“administrative admission.” Thereby, the patient administration system can send 
Mr. Russo’s administrative data to the RIS. If the RIS is syntactically interoperable 
as well, it will be able to incorporate these data in its database. 


3.7.1.3 Semantic Interoperability 


Two application systems are semantically interoperable if they are syntactically 
interoperable and can exchange information (in the form of messages) that can be 
meaningfully interpreted by both and processed further. 

We can also say that the information transferred is not only “machine-readable” 
but also “machine-processable.” This means that the application system can “under- 
stand” the content of messages and act accordingly, for example, by using data for 
automatic decision support. Beyond mere syntactic agreement between two actors 
and agreement on data types or structures defined in a reference model for data 
representation, a prerequisite for this mutual understanding is a homogeneous, 
jointly agreed definition of the underlying content concepts, for example, a clinical 
concept such as “systolic blood pressure.” Such concepts are called detailed clinical 
models. To achieve this, two application systems must adhere to such content mod- 
els which define possible content (e.g., as openEHR archetypes) or actual content 
(e.g., as HL7 FHIR resources or openEHR templates, Sect. 3.7.2.8). 

Modelers who create detailed concept representations which are used for com- 
munication between systems or for querying data repositories frequently draw on 
already existing specialized terminology standards or terminologies such as 
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SNOMED and LOINC (Logical Observation Identifiers Names and Codes) to 
enhance their models. Thus, they support semantic interoperability, as they provide 
a common and unambiguous vocabulary within shared information models (Sect. 
3.8.2) between application systems. LOINC and SNOMED are presented in more 
detail in Sects. 3.7.2.9 and 3.7.2.10. 

An information model describes the entity types and their relationships at a con- 
ceptual level, independent of any specific implementation or protocols. Information 
models are intended for designers. In contrast, a data model is defined at a lower 
level of abstraction. Data models are intended for implementers of databases. 

In addition to these two terminologies, also known as nomenclatures, there are 
numerous classifications in medicine. Classifications are mainly used for statistical 
purposes, for example, counting similar objects, or for grouping similar treatment 
cases together for billing purposes. Occasionally, however, they are also used to 
support semantic interoperability although they were not actually designed for this 
purpose. 

Some examples of classification systems used in health care are presented in 
Table 3.18. 

Please note that semantic interoperability cannot be achieved without technical 
and syntactic interoperability. The ability to exchange structured messages is the 
precondition for exchanging meaningful data. If application systems have agreed to 
exchange, for example, LOINC codes within a message, the receiver can automati- 
cally extract these LOINC codes. To be semantically interoperable, the application 
system must be able to interpret the extracted LOINC code and understand the 
context in which it is used. 


3.7.1.4 Process Interoperability 


Finally, process interoperability addresses whether application systems are able to 
cooperate in certain organizational contexts, especially in certain processes, by 
meaningfully exchanging information. Such processes may involve, for example, 
ordering a radiological examination and then sending back the findings or providing 
a document for use outside one’s own facility and then using the document from 


Table 3.18 Examples of classification systems used in health care 


Classification systems in health care Concepts represented 
NANDA—North American Nursing Diagnosis Nursing diagnosis 
Association 
NIC—Nursing Intervention Classification Nursing interventions 
l NOC—Nursing Outcome Classification Nursing outcomes 
1CF—International Classification of Functioning, Health and social status, disabilities 
Disability, and Health 
ICD—International Classification of Diseases Medical diagnosis 
-ICNP—International Classification of Nursing Practice | Nursing problems, interventions, and l 
outcomes 
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outside. Process interoperability depends on successful technical, syntactic, and 
semantic interoperability. 

An application system is interoperable with respect to a particular process if it is 
syntactically interoperable and capable of both sending all messages required for 
the collaborative processing of that process and correctly interpreting the messages 
received. Through this communication, the application system must be able to cor- 
rectly fulfill the role it has been assigned in this process. 

The more business-related the processes to be supported are, i.e., the more they 
correspond to the function in Sect. 3.3, the more semantic interoperability an appli- 
cation system must have. 

Process interoperability requires the ability to handle many send and receive 
operations in a specific way and sequence required by the supported process. Since 
the communication standards mentioned so far essentially refer to individual send- 
ing and receiving operations, regulations are required that relate to the complex 
organizational context and the processes to be supported. IHE provides such regula- 
tions in the form of the so-called profiles. The IHE organization offers to review and 
certify application software products to determine whether they are interoperable 
with respect to a specific process and profile. 

Although these profiles merely describe the use of existing interoperability stan- 
dards, they have now taken on a normative character. For this reason, we also 
describe IHE in Sect. 3.7.2.5. 


3.7.2 Interoperability Standards 


As said before, the costs of the implementation and maintenance of interfaces within 
heterogeneous health information systems can be significantly reduced when stan- 
dards for interoperability are used. Furthermore, mapping processes are usually 
accompanied by a loss of information or semantics. 

Within the logical tool layer of health information systems, there exist standards 
for syntactic interoperability (also called communication standard or message stan- 
dards), for semantic interoperability (common information models, terminology 
standards), and for process interoperability. For technical interoperability there is, 
for example, the already mentioned REST standard at the logical tool layer. This is 
complemented by so-called protocols at the physical tool layer, which will be dis- 
cussed in Sect. 3.10.2. 

An abundance of standards exists, some covering more than one aspect of 
interoperability. Thus, it is not trivial to assign them to the above-mentioned levels. 

As the most widely implemented and well-established standards, HL7 V2 mes- 
sages and DICOM will be described. However, there are more. HL7 CDA is a stan- 
dard for structuring medical documents and contributes to syntactic interoperability. 
HL7 FHIR simplifies the exchange of clinical data between heterogeneous applica- 
tion systems using web technologies for data transfer. DICOM allows digital images 
and related metadata to be shared. IHE in general focuses on workflow processes 
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and enables process interoperability by providing guidelines on how to apply other 
standards, for example, DICOM, HL7 V2, and HL7 FHIR. In particular, Integrating 
the Health care Enterprise Cross-Enterprise Document Sharing (IHE XDS) focuses 
on content-agnostic, i.e., encapsuled, sharing of documents within and across differ- 
ent health care organizations. For the exchange of bio-signals and vital signs 
between point-of-care devices, the ISO/IEEE 11073 standard is available. openEHR 
focuses on the representation of clinical information in detailed clinical models and 
allows for the creation of a semantically fully defined EHR. SNOMED CT is a uni- 
versal, multilingual clinical terminology for supporting semantic interoperability 
that includes more than one million relationships of different types between con- 
cepts. LOINC also supports semantic interoperability and is the most widely used 
standard for measurements and tests in health care, for example, laboratory tests. 
The Clinical Data Interchange Standards Consortium (CDISC) provides a number 
of standards, of which ODM-XML (Operational Data Model) is well-known for the 
representation of clinical research (trial) data and metadata, being widely used in 
electronic data capture (EDC) systems. 

We will now discuss some of these standards in more detail. The list is by no 
means complete, with new standards emerging and others disappearing frequently, 
as well as current ones changing. 


3.7.2.1 Health Level 7 Version 2 (HL7 V2) 


Health Level 7 Version 2 (HL7 V2) [9] is the most-implemented communication 
standard in hospital information systems for the transfer of messages with data on 
the entity types “patient” and “case” and the other entity types as described in Sect. 
3.2.3, but excluding image data. 

HL7 V2 has been maintained by the international standards organization 
Health Level Seven International (HL7) since the 1990s. It can be best considered 
as a standard to support mainly syntactic interoperability between application 
systems. 

HL7 describes event types and dedicated message types that are exchanged 
between application systems when triggered by a specific event. 

HL7 assumes that a message is sent from application system A to another appli- 
cation system B through the occurrence of an event of certain event type (Fig. 3.28). 
The message type that is used for the message depends on the occurring type of 
event. The message type describes the structure of the sent message and determines 
the meaning of the individual parts of the message. 

Following the arrival of the message, application system B confirms the receipt 
of the message through a receipt message (ACK) that is sent back to application 
system A. If a communication server such as in Sect. 3.9.2 is used to send a mes- 
sage, for example, from the patient administration system to the LIS, then the com- 
munication server first takes over the role of the receiving application system B. As 
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Fig. 3.28 Event-driven com- 
munication with HL7 V2 
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a second step, the communication server, as the sending application component A, 
sends the message to LIS, which takes over the role of B. 

HL7 possesses an extensive catalog of event types. For example, A01 describes 
the event “admission of a patient,’ A02 “transfer to another organizational unit,” 
A03 “discharge of a patient,” and ROI “completion of an examination result.” 

In addition, HL7 provides a list of standardized message types, such as admis- 
sion, discharge, and transfer (ADT), for messages related to admission, discharge, 
and transfer of patients. Other message types are ORM for a general order message 
(e.g., ordering a radiological examination), ORU for an unsolicited observational 
result (e.g., radiology report), and BAR for patient accounting message. 

Message types are assigned to event types. For example, if the L/S in the labora- 
tory of a hospital registers the occurrence of an event of type R01, then it can send 
a message of message type ORU. 

All HL7 V2 messages are structured into segments, with each segment containing 
fields. For example, the ADT message contains at least the following segments: mes- 
sage header (MSH), event description (EVN), patient identification (PID), and 
patient visit information (PV1). With each segment, the relevant information is pro- 
vided in different fields, each separated by “I”. The following example shows a very 
simplified pattern of an ADT message where a patient is admitted to a specified ward: 


MSH | SENDING COMPONENT | RECEIVING COMPONENT|DATE OF MESSAGE | 
EVN |A01 |DATE OF EVENT | 
PID|PATIENT IDENTIFIER|NAME*FIRST NAME|BIRTH OF DATE|SEX| 
PV1|PATIENT CLASS|WARD ID|DATE OF ADMISSION | 


Despite this standardization, the use of “plug and play” equipment is often not 
possible due to various reasons. On the one hand, HL7 leaves users with a certain 
degree of freedom with regard to semantic interoperability. Consensus must be 
reached between the communicating application systems, whether, for example, the 
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choices “male.” “female,” “other,” and “unknown” for gender can be documented as 
“m”, “f’, “o”, and “u”, with “0”, “1”, “2”, and “3”, or in some other fashion. 
Furthermore, there also exists the problem of using catalogs of terms. For example, 
if a CIS wants to order a radiological examination, it must have an up-to-date copy 
of the service catalog of the radiological unit. 

On the other hand, manufacturers of application software products sometimes 
offer HL7 interfaces to their products that cannot send or receive all required event 
types and/or all necessary message types. In this case, a thorough analysis is neces- 
sary before deciding on a purchase. 

Finally, there exist different sub-versions of HL7 V2 (2.1, 2.2, 2.3, 2.4, 2.5, 2.6) 
which partly differ in their definition of message content. 

When a message was constructed in accordance with the previous explanations, 
it is left up to the particular implementation how communication between the physi- 
cal data processing systems will occur. A message can then, for example, be written 
in a text file or transported by disk or using an FTP file transfer. The exchange for- 
mat and protocol for technical interoperability at the physical tool layer is to be 
decided on in every single communication link. 


3.7.2.2 Clinical Document Architecture (CDA) 


The Clinical Document Architecture (CDA) is an XML-based document standard 
for storing and exchanging clinical content in the form of documents (e.g., a dis- 
charge letter, a lab finding). CDA was developed and is maintained by the HL7 
organization and has been accredited by ANSI, the American National Standards 
Institute. 

CDA is one element of the Health Level 7 Version 3 (HL7 V3) standard. HL7 V3 
is a message standard developed by the HL7 organization in the 2000s. Unlike HL7 
V2, where messages were developed in a pragmatic way, messages in HL7 V3 are 
derived from an information model, the so-called HL7 Reference Information 
Model (RIM). 

The message encoding within CDA is based on XML, thereby supporting syn- 
tactic interoperability. CDA documents are persistent records of medical informa- 
tion (such as diagnostic findings, discharge summaries, or lab reports). CDA 
supports free text as well as fully structured, machine-processable information, thus 
also supporting semantic interoperability. Document templates (so-called imple- 
mentation guidelines) define CDA-based document structures for specific use cases 
such as a discharge summary or a radiology report. CDA is used in several countries 
for sharing clinical documents on a national level. 

CDA documents comprise two parts: the CDA header that presents metadata on 
the document such as sending institution, patient name, and type and date of docu- 
ment; and the CDA body that contains the specific information (e.g., the lab result). 

The following example (adapted from [10]) shows a very simplified extract 
of an XML-based lab result message from the CDA body. The elements specify 
the type of observation (glucose 12 h fasting), the time of the observation 
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(February 15, 2021, 7.30 a.m.), and the status (the observation is completed). 
The value for the actual result is shown in the value element (182 mg/dL), and 
the data type is PQ = physical quantity. The glucose lab value is also given in 
coded form (1554-5), which is a code from the LOINC system (“LN,” Sect. 
3.7.2.10). Using LOINC codes supports semantic interoperability. LOINC is 
uniquely identified by the LOINC Object Identifier (OID) 
(“2.16.840.1.113883.6.1”). All relevant terminology systems in health care pos- 
sess a unique OID which allows application systems to exchange the informa- 
tion which terminology systems is being used. 


<observationEvent> 

<id root="2.16.840.1.113883.19.1122.4"> 

<code code="1554-5" codeSystemName="LN" codeSystem= 
"2.16.840.1.113883.6.1" displayName="GLUCOSE*POST 12H"/> 
<effectiveTime value="202102150730"/> 

<statusCode code="completed"/> 


<value xsi:type="PQ" value="182" unit="mg/dL"/> 
</observationEvent> 


Since HL7 V3 is not compatible with HL7 V2 and a “translation” between both 
formats is not trivial, HL7 V3 is primarily used for transinstitutional message 
exchange for which version 2 is not well suited. Both HL7 versions can be expected 
to coexist for a longer time. 


3.7.2.3 Health Level 7 Fast Health care Interoperability Resources 
(HL7 FHIR) 


HL7 FHIR (Fast Health care Interoperability Resources) is a recent HL7 standard 
based on the experience from other HL7 standards that was developed in and has 
been continuously updated since 2014. The standard is built upon web technologies, 
most notably REST APIs and simple HTTP operations. The focus is on sharing 
medical data in terms of transferring them from one application system to another 
in a standardized manner and thus make medical data portable. FHIR supports tech- 
nical interoperability (by using web technology standards), syntactic interoperabil- 
ity (via clearly defined resources), and semantic interoperability (via an underlying 
information model and the use of reference terminologies). 

The two basic building blocks are information models called “resources” which 
represent clinical, identifying, or financial information as well as APIs. The basic 
resources follow the so-called 80/20 approach, i.e., to meet 80% of the needs by 
implementing 20% of the requirements. FHIR neither aims to cover all clinical 
information nor to implement an EHR but pragmatically focuses on frequent, 
generic use cases. HL7 develops the FHIR specification and manages the resources, 
for which it also defines a number of rules on how to create them. FHIR provides 
terminology linking and validation. 
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To implement specific clinical use cases, generic FHIR resources are adapted 
into “profiles,’ or more specific information models. Thus, institutional or local 
adaptations are implemented, albeit with a trade-off towards loss of 
interoperability. 

Apart from supporting data sharing by providing mechanisms for interfacing dif- 
ferent application systems with likely diverging underlying information models and 
persistence structures, a native “FHIR server” implements a set of APIs and 
resources and allows for operations, for example, to create, update, or search 
resources. 


3.7.2.4 Digital Imaging and Communications in Medicine (DICOM) 


Digital Imaging and Communications in Medicine (DICOM) [11] is an open stan- 
dard maintained since the 1980s by the DICOM Standards Committee of the 
National Electrical Manufacturers Association. DICOM addresses the integration 
requirements of the medical imaging sector. 

DICOM supports technical interoperability at the physical tool layer (by defining 
network protocols such as Transmission Control Protocol/Internet Protocol (TCP/ 
IP)), syntactic interoperability (by its message formats), and—to some extent— 
semantic interoperability (by an underlying information model). 

DICOM defines not only file and message formats for all types of medical 
imaging modalities (e.g., computed tomography, digital X-ray, magnetic reso- 
nance imaging, ultrasound, nuclear medicine imaging), but also a network proto- 
col at the physical tool layer with a set of well-defined network services. These 
services permit, for example, an imaging modality to retrieve a “worklist” 
describing the patients to be examined from the R/S, to transmit the images and 
X-ray dose information created during an examination to the PACS, to confirm 
that the images have been archived successfully (and can thus be deleted locally), 
and to notify the R/S that the imaging procedure has been completed. Other ser- 
vices permit a diagnostic workstation to retrieve current and prior imaging stud- 
ies, to print a hardcopy on a medical printer, or to store a report and results of 
measurements performed on the images. Unlike HL7 V2, the DICOM standard 
defines a complete network protocol stack (based on TCP/IP, Sect. 3.10.2) using 
efficient binary encoding and, optionally, image compression techniques. The 
capabilities of two communicating systems (such as the services and encodings 
supported by both systems) are dynamically negotiated whenever a new network 
connection is initiated, which permits a tight integration because systems can to 
some degree adapt to the capabilities of their communication peers. DICOM has 
gained widespread acceptance in the medical imaging sector as well as in all 
medical disciplines that rely heavily on digital images (in particular radiology 
and cardiology). 
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It should be noted that the RZS is also dependent on messages from the patient 
administration system and must also send, for example, billing data there. As discussed 
above, this communication should be carried out on the basis of HL7 V2. Orders from 
wards and outpatient units will also most likely reach radiology as HL7 messages, 
whereas the results and images will come back as DICOM messages. The common 
initiative IHE (Sect. 3.7.2.5) has taken on the task of settling this complex interplay. 


3.7.2.5 Integrating the Health care Enterprise (IHE)—Integration Profiles 


Integrating the Health care Enterprise (IHE) is an organization founded by medical 
professional societies in 1998 together with the health care IT industry [12]. Its aim 
is to improve the integration of application systems in health care and to check and 
certify if application software products to be used for the application systems have 
the process interoperability needed for this integration. 

The approach taken by IHE is to analyze typical work processes occurring in 
health care. IHE identifies the application systems involved in these processes and 
the information that should be exchanged between these application systems to sup- 
port the diagnostic and therapeutic processes as good as possible. For example, IHE 
has defined working processes in the form of “integration profiles” for areas such as 
cardiology, pathology, radiology, and pharmacy. It has also defined integration pro- 
files for the exchange of clinical documents between different health care facilities 
(IHE XDS, Sect. 3.7.2.6). 

THE then selects existing standards, i.e., especially HL7 V2 and DICOM, for 
each “transaction” (information exchange between application systems) and 
restricts the options offered by these standards for each transaction so that plug-and- 
play interoperability becomes possible. 

By defining work processes, IHE supports process interoperability. Together 
with standards such as HL7, HL7 CDA, HL7 FHIR, openEHR, and DICOM, it 
indirectly supports syntactic and semantic interoperability. 

IHE furthermore offers comprehensive test software enabling vendors to test 
their products’ interfaces for IHE-conformant process interoperability and orga- 
nizes large cross-vendor testing events called “IHE Connectathons” (from “connec- 
tion” and “marathon’’). 

THE is not a standards body as such but fills a very important gap by selecting the 
most appropriate set of standards for a typical clinical workflow. It reduces the inde- 
terminacy of the way of interaction, for example, between HL7 V2 and DICOM, by 
proposing clear rules for their joint use. The resulting technical specifications are 
published annually as the IHE Technical Frameworks. 

Although the profiles are not communication standards, they gain normative 
character through their increasing dissemination and can be regarded as quasi- 
standards for the use of communication standards. 
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Fig. 3.29 IHE XDS.b actors and interactions (simplified), using the example of a radiology report. 
#1—#6 indicate order of messages 


3.7.2.6 IHE Cross-Enterprise Document Sharing (XDS) 


One of the above-mentioned technical frameworks is the IT Infrastructure 
Framework (ITI), which specifies standards-based implementations for exchanging 
clinical information. Among other things, it describes how to share documents 
between different health care organizations. IHE Cross-Enterprise Document 
Sharing (IHE XDS) is used, for example, for the Austrian ELGA (national EHR) 
and partly in the German Medical Informatics Initiative. 

IHE XDS defines neither the content of these documents nor their internal struc- 
ture, making it “content-agnostic.” Instead, it defines actors along with their interac- 
tions and integration profiles of both these components. IHE XDS.b is a prominent 
integration profile defining affinity domains and actors. 

Figure 3.29 shows the actors in this profile and their interactions. A source sys- 
tem (e.g., an RIS) provides a new document, for example, a radiology report on Mr. 
Russo, along with its metadata to the document repository. This document is then 
registered in a document registry. A document consumer, for example, another clini- 
cal application system, such as the MDMS, at a different site in the health care net- 
work, can query the document registry to locate a relevant document and then query 
and subsequently retrieve this document from the decentral document repository. 
Document repositories are usually decentral, while the registry is central. 


3.7.2.7 ISO/IEEE 11073 


The ISO/IEEE family of standards for the exchange of data between medical devices 
comprises, for example, a standard for exchanging bio-signals and vital parameters 
between point-of-care devices [13]. Furthermore, the standard enables a dynamic 
exchange and reconfiguration of devices and remote control, for example, of infu- 
sion pumps. 
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Medical devices can be considered as combining an application system at the 
logical tool layer with a dedicated physical data processing system at the physical 
tool layer, which is often also called an appliance. 

ISO/IEEE 11073 can be used, for example, to receive and display data from infu- 
sion pumps, respirators, ECGs, etc. on patient monitors in the ICU and for integrat- 
ing medical devices in operating rooms. It is also used for receiving data from 
mobile wellness devices (e.g., fitness tracker) and personal health applications (e.g., 
diabetes app). 

ISO/IEEE 11073 supports technical interoperability by defining a complete com- 
munication protocol stack and, for example, includes binary encoding of data that is 
optimized for near-real-time transmission. It also supports syntactic interoperability 
by defining the formatting and syntax for the exchanged messages. 

While ISO/IEEE 11073 enables the exchange of especially vital parameters 
between the application systems of the medical devices, HL7 V2 and DICOM facil- 
itate the data exchange between the application systems mentioned in Sect. 3.4. 
However, it is also necessary to be able to exchange data between these worlds. For 
example, patient demographic data is also required for the devices, and vital param- 
eters should be able to be transferred to the EHR. Gateways are used to realize this 
communication. 


3.7.2.8 open Electronic Health Record (openEHR) 


openEHR (open Electronic Health Record) is an open standard specification which 
focuses on the standardized representation of clinical information in EHRs. It has 
been maintained by the openEHR Foundation since the early 2000s and supports 
semantic and syntactic interoperability. 

The specification follows a detailed (maximum) clinical information modeling 
approach and provides a formalism—the archetype definition language (ADL)— 
to define archetypes as the basic building blocks representing clinical concepts. 
Furthermore, it includes the archetype query language (AQL), which—while syn- 
tactically similar to the ubiquitous SQL—operates on clinical concepts and— 
unlike SQL—requires no knowledge of the persistence data structures (e.g., 
database schemata). 

openEHR follows a two-layer modeling paradigm, fundamentally separating 
clinical content from technical details. The first layer is the reference model, which 
describes the smallest logical blocks along with their implementation, for example, 
data types and structures or basic EHR components. As part of the archetype model, 
the second layer defines the domain model representation in a maximum approach, 
meaning that an archetype (e.g., blood pressure or height), as the most basic and 
self-contained clinical concept, should serve all potential uses of this concept within 
the health care domain. 

In other words, archetypes are reusable as semantic building blocks in different 
contexts without further modification. Within an archetype, each single item or data 
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instance can be linked or bound to a terminology (e.g., LOINC or SNOMED CT). 
Archetype classes include “composition”, “section,” and “entry,” whereby the latter 
again includes “observation,” “evaluation,” “instruction,” “action,” and “cluster.” To 
create more complex information units on the basis of these interchangeable build- 
ing blocks in the context of specific use cases, openEHR uses templates. An opera- 
tion report, the results of an assessment test, or a form/document could, for example, 
be represented as templates, each assembled using archetypes just like construction 
bricks. A number of tools support the collaborative creation of openEHR archetypes 
and templates by clinicians and modelers, their governance, and the automated cre- 
ation of software artifacts from them, which can be used in application systems of 
all kinds. 

openEHR enables the definition of a complete EHR along with methods to struc- 
ture the EHR and manipulate its contents, for example, by writing (adding) compo- 
sitions to the record. It also includes versioning. The open specification includes 
openly available REST APIs for programmers and vendors and supports several 
implementation/representation formats. Finally, it makes it possible to build a full, 
vendor-independent EHR within and across health care facilities. 
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3.7.2.9 Systematized Nomenclature of Medicine Clinical Terms 
(SNOMED CT) 


SNOMED was developed in the 1970s and is maintained by SNOMED International, 
a non-profit international standards organization. SNOMED CT (Systematized 
Nomenclature of Medicine Clinical Terms), first published in 2003, is currently the 
most comprehensive terminology in the health domain and is used in many coun- 
tries worldwide. Users must obtain a license for use. The nomenclature aims to 
support the development of high quality, precisely defined content by standardizing 
medical terms and by providing ontological components such as associations and 
relationships between encoded concepts and entities. 

SNOMED CT supports the semantic interoperability of application systems. It 
can be used for encoding and exchanging machine-processable data. SNOMED CT 
codes (like other codes from terminology standards) can be embedded in informa- 
tion models of other standards such as HL7 FHIR or openEHR. 

SNOMED CT consists of concepts, descriptions, and relationships. A con- 
cept represents a unique clinical concept such as diabetes mellitus (disorder), 
which has several children concepts, such as diabetes mellitus type 1 or diabe- 
tes mellitus type 2, and so on (Fig. 3.30). Each further level in the hierarchy 
represents a more specific concept (partitive or taxonomic relationship). 
Associations between concepts may be of different types, for example, is-a 
(diabetes mellitus is a disorder of the endocrine system) or finding-site (struc- 
ture of the endocrine system). SNOMED CT also contains synonyms and is 
available in multiple languages. 
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Fig. 3.30 SNOMED CT example of associations between concepts. (Taken from the SNOMED 
CT browser [14]; use of SNOMED CT is with the permission of SNOMED International) 


3.7.2.10 Logical Observation Identifiers Names and Codes (LOINC) 


Logical Observation Identifiers Names and Codes (LOINC) is a widely used termi- 
nology system for health measurements, tests such as laboratory and clinical tests, 
and observations. LOINC was developed in the 1990s and is maintained by the 
Regenstrief Institute in the United States [15]. 

The system defines unique names, codes, and identifiers that can be used in 
application systems or within communication messages such as HL7 or DICOM 
messages as well as in CDA documents (Sect. 3.7.2.2 shows an example of this), 
openEHR archetypes, or FHIR profiles. LOINC thus supports the semantic interop- 
erability of application systems. 

LOINC codes are constituted of six components, for example, LOINC 
code 1554-5: 


1. component (analyte): what is measured, for example, Glucose“post 12H CFst, 

2. property: the attribute or characteristic measured, for example, mass concentra- 
tion (MCnc), 

. time: the point or interval of time, 

. system (specimen), for example, serum/plasma, 

. scale: type of value, for example, numerical quantitative (Qn), such as “125”, 

. method (optional): classification of the measurement/observation method. 


NN BW 


The LOINC “long common name” for this code example is “Glucose [Mass/ 
volume] in Serum or Plasma --12 hours fasting.” 


3.7.2.11 Clinical Data Interchange Standards Consortium (CDISC) 


The Clinical Data Interchange Standards Consortium (CDISC) spans a wide variety 
of standards, which are mainly—but not exclusively—designed for and used in 
clinical studies and trials in the pharmaceutical industry. CDISC standards were 
developed in the late 1990s and are maintained by the non-profit Clinical Data 
Interchange Standards Consortium. 
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CDISC standards are free to use and cover different domains and parts of the 
complete process to develop clinical products such as new drugs. The use of some 
of these standards is mandatory for reporting and submitting results from clinical 
trials to regulatory authorities, for example, to the FDA (U.S. Food and Drug 
Administration). 

Common CDISC standards include the “foundational standards,” which cover all 
necessary processes within research studies. Along the evolution of a research study, 
these standards cover planning (model for planning: Protocol Representation 
Model), data acquisition (model for data collection: Clinical Data Acquisition 
Standards Harmonization), organizing and managing data (e.g., Study Data 
Tabulation Model (SDTM), model for Questionnaires, Ratings, and Scales), and for 
data analysis (Analysis Data Model). 

SDTM is the standard in which study data are submitted to regulatory authori- 
ties. Apart from these foundational standards, CDISC also supports a controlled 
terminology and includes widely used standards for data exchange, such as 
ODM-XML. 

By employing these CDISC standards, researchers can achieve syntactic and 
semantic interoperability, share their data and metadata, and use a variety of 
software solutions (e.g., different EDC systems and analytical tools) along the 
study process. 


3.8 Logical Tool Layer: Types of Integration 


Interoperable application systems can be joined together, i.e., integrated, in such a 
way that their combination has new properties that the application systems did not 
have on their own. Integration is a union of parts making a whole, which—as 
opposed to its parts—displays a new quality. 

Integrating application systems lead to integrated health information systems. 
An integrated computer-based health information system typically offers better sup- 
port for functions and business processes than a non-integrated information system 
consisting of isolated application systems. In non-integrated information systems, 
users may, for example, need to manually transfer data from one application system 
to another, or inconsistencies between data representations and semantics may exist 
that hinder the multiple use of data. 

There are various ways of integrating application systems, resulting in different 
types of integration. Each type of integration leads to specific new properties of the 
information system. In this section, you will learn about the following types of inte- 
gration in more detail: 


e data integration, 

e semantic integration, 

e user interface integration, 
e context integration, 


3.8 Logical Tool Layer: Types of Integration 129 


e feature integration, 
e process integration. 


Note that the basic prerequisite for all types of integration is that the application 
systems to be integrated must be technically and syntactically interoperable so that 
communication is possible at all. 

While interoperability makes a statement about a single application system or 
about a single application software product and its specific properties and capabil- 
ity, integration always refers to a set of application systems and the way they are 
connected in a specific information system. 


3.8.1 Data Integration 


Data integration is achieved in integrated health information systems when data 
that have been recorded and stored once in one application component are made 
available in a coherent and uniform way wherever they are needed, i.e., in other 
application components, without having to be reentered. Data integration has two 
effects: 


e Data on different entity types being recorded and stored in different application 
systems can be combined for joint analysis and use in one particular applica- 
tion system. 

e New data on entity types need to be recorded, changed, deleted, or otherwise 
edited just once—even if the data are to be used in several application components. 


In DB! architectures, i.e., architectures with a central database, data integration 
is comparatively easy to achieve. Open platforms are a technology that can be used 
to implement this even in (AC", V") architectures (Sect. 3.9.3). 

In case of a decentralized DB" architecture, data integration and a uniform view 
on the data is more challenging. Transaction management and communication serv- 
ers are integration technologies suitable to meet this challenge (Sects. 3.9.1 
and 3.9.2). 

Data integration helps to increase data consistency (Sect. 3.5) and to reduce 
unnecessary double data entry: 

Assume that Mr. Russo was treated in the cardiology department, and a detailed 
medical history was collected and entered into the MDMS. Now Mr. Russo’s health 
is deteriorating dramatically, and he must be moved to the ICU of the same hospital. 
If the medical history needs to be documented again, in case the information from 
the cardiology department cannot be accessed, there would be no data integration. 
If the ICU can assess and add data to the existing medical history, regardless of 
where and in which application system the already existing data was entered, data 
integration is achieved. In this example, the medical history may be sent from the 
MDMS to the PDMS, either directly or via respective integration technology and 
tools (Sect. 3.9). 
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To support data integration with non-computer-based application components, 
computer-based application components need to be able to print out data or to scan 
data such as paper-based documents (e.g., signed patient consent documents or a 
paper-based order entry form). 


3.8.2 Semantic Integration 


Like data integration, semantic integration is concerned with data. Semantic inte- 
gration is achieved when semantically interoperable application systems actually 
use the same system of concepts, i.e., they interpret data the same way. For example, 
when the sending application system uses the abbreviation “GOT” for a lab value, 
but the receiving application system does not know this code and uses “ASAT” for 
the same concept instead, then semantic integration is not achieved. 

To achieve semantic integration of application systems, the application systems 
must agree on the way that information is represented, for example, within a hospi- 
tal or a network of care facilities. This means that there needs to be an agreement on 
a common information model, for example, on Mr. Russo’s blood pressure. This 
agreement comprises two aspects: We need to agree on how to actually represent the 
data values (e.g., systolic and diastolic values) by data. And we also need to agree 
on the underlying clinical concept and represent metadata such as the context of the 
measurements (resting blood pressure or exercise test), the measurement method 
(cuff or intra-arterial on an ICU), and so on. Contextual information can make a 
huge difference. For example, for a clinical decision support system (CDSS), which 
tries to interpret the blood pressure values to determine whether the value is normal 
or abnormal in a specific situation. Development of such information models is 
time-consuming multi-professional work, and agreeing on and maintaining them 
requires effort and strict governance of models. In the long term, however, these 
information models reduce tedious and costly mapping work and maintenance of 
mapping tables between application systems. Furthermore, it enables the reuse of 
data in contexts that differ from the original scenario in which the data was recorded, 
for example, for research or clinical decision support (CDS). 

Thus, for semantic integration, the application systems must agree on some com- 
mon terminologies. However, using terminology systems such as LOINC, 
SNOMED, or ICD (Sect. 3.7.1.3) does not guarantee semantic integration. Instead, 
for real semantic integration, application systems must also agree on common infor- 
mation models. Such common information models contain a set of abstract con- 
cepts (e.g., patient, case, observation, entry, series of pictures) which are close to 
our concept of entity types and their relationships among each other. They thus try 
to formally represent the reality of health care through a set of concepts and their 
relationships. If two application components agree on the same information model, 
exchange of information and thus semantic integration are facilitated. Both 
openEHR (Sect. 3.7.2.7) and HL7 FHIR (Sect. 3.7.2.3) enable the creation of com- 
mon information models, derived from a reference model. 


3.8 Logical Tool Layer: Types of Integration 131 


Semantic integration can be elegantly and thoroughly supported by health data 
dictionaries. Such medical data dictionaries are central catalogs of health-related 
concepts and terms that offer the possibility of representing the semantic relation- 
ships among all data stored in a health information system and of linking that local 
vocabulary to internationally standardized nomenclatures and knowledge sources 
(“terminology linking” in openEHR). Such health data dictionaries (sometimes also 
called Medical Data Dictionaries, MDD) can be independent application compo- 
nents or part of existing application components. 


3.8.3 User Interface Integration 


User interface integration is guaranteed when different application systems repre- 
sent data and organize their user interfaces in a unified way. For example, different 
application systems should display the patient’s name always at the same place on 
their user interface. Icons for patients should code gender with the same colors. 
Alerts and warnings should be presented using the same colors and layout. Or the 
birthdate of a patient should also be displayed in the same format (e.g., yyyy-mm-dd). 

The responsibility for integrating application systems in such a way that user 
interface integration is achieved lies with tactical management of information sys- 
tems (Sect. 4.4). Especially at the specification stage of a new application software 
product, the relevant user interface requirements must be clearly described. This can 
be supported by user interface guidelines that are commissioned by standardization, 
governmental agencies, or leading health IT vendors. 


3.8.4 Context Integration 


Even if data, semantic, and user interface integration is ensured, problems can arise 
when users use multiple application systems on one workstation, as the user and 
patient context may become lost through the change from one application system to 
another. Context integration is achieved if the context is preserved when the appli- 
cation system is changed. Or, more generally, the aim is that a task that has already 
been executed once for a certain purpose, such as login to a component or selecting 
a patient, does not need to be repeated again in the information system in order to 
achieve the same purpose. 

Assume that the nurse Peter Smith first wants to order a lab examination for the 
patient Jakub Russo at his workstation before documenting certain nursing proce- 
dures. The nurse would first log in to the CPOE system and create the user context 
“Peter Smith.” Then Peter searches for the patient Jakub Russo and orders the 
requested examination for him. This creates the patient context “Jakub Russo.” For 
the next task, the nurse would have to start the NMDS. Without context integration, 
the user context “Peter Smith” would not be created in this application system 
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automatically and Peter would have to log in again. And without context integration, 
Peter would have to again select the patient and restore the patient context “Jakub 
Russo” before being able to document the nursing procedures. Context integration 
would be achieved when both login (then also called “single sign-on”) and patient 
selection (maybe called “single patient look-up”) do not have to be repeated again, 
even when changing the application system. 

Health Level 7 provides a standard for single sign-on and single patient lockup, 
called CCOW (Clinical Context Object Workgroup). 


3.8.5 Feature Integration 


Feature integration is achieved when features needed in more than one application 
system are implemented only once and can be invoked by other application systems. 

In a hospital, for example, coding of diagnoses and procedures is a feature that 
should be supported by the patient administration system, the OMS, the RIS, and the 
LIS. The health information system would display feature integration with respect 
to coding of diagnoses and procedures if only one application component (e.g., the 
patient administration system) provides the features needed for coding diagnoses 
and procedures and all other application components can invoke and use these 
features. 

Feature integration reduces the need to exchange data between application sys- 
tems, reduces the danger of inconsistent data, and decreases the need to train users 
on multiple application systems. 

On the technical level, feature integration can be supported by providing the use 
of features as services within an SOA (Sect. 3.9.3). Those services can be invoked 
by other application systems. 

Overall, feature integration is an important quality characteristic within hetero- 
geneous health information systems, as it allows features to be shared among appli- 
cation systems. 


3.8.6 Process Integration 


An integrated health information system should support the business processes 
effectively. From this perspective, process integration is indeed the overall vision of 
integration within heterogeneous information systems, i.e., especially in (AC", V”) 
architectures. 

Process integration is guaranteed when business processes are effectively sup- 
ported by a set of cooperating application systems showing process interoperability. 

Typically, as we have seen, functions of a health care setting are supported by 
many different, yet interrelated application systems. A user must therefore use dif- 
ferent application systems for one task. 
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For example, while writing the radiological report on Mr. Russo, the radiologist 
must work with the CIS, the RIS, and the PACS. To enable effective work in this 
process, these application systems should interoperate as transparently and smoothly 
as possible. If the radiologist receives the best possible support in report writing, 
without any interruption due to the heterogeneity of application systems, then we 
can say the information system is process integrated. 

Obviously, process integration builds to some extent on the other integration 
qualities such as data integration (CIS, RIS, and PACS are able to exchange and 
jointly use patient diagnosis data without the need to reenter it), user interface inte- 
gration (e.g., CIS and RIS have comparable user interfaces), context integration 
(e.g., when shifting between CIS and RIS, user patient context is maintained), 
semantic integration (e.g., procedures documented in the RIS are automatically 
understood by the patient administration system), and feature integration (the RIS 
invokes the billing function of the patient administration system). Good process 
integration builds on this, supports comprehensive information logistics, and pre- 
vents users from transcription and media breaks. 

Process integration can be achieved, among other things, through the adoption of 
IHE profiles (Sects. 3.7.2.5 and 3.7.2.6) on a systematic basis. 

Overall, process integration is an important quality characteristic within hetero- 
geneous health information systems, as it describes a situation where different 
application systems interoperate in an optimal way so that business processes are 
best supported. 
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To achieve data integrity (Sect. 3.5) and to support various types of integration 
(Sect. 3.8) in AC" architectures, specific integration technologies are available. 
These integration technologies support interoperation of application systems and 
efficient and secure health information exchange between health care providers, and 
in some cases also with patients. 

In this section, you will learn about transaction management, communication 
servers, vendor-neutral archives, and SOAs as examples of this kind of integration 
technologies. 


3.9.1 Transaction Management 


Transaction management ensures that every update of correct data in one or more 
databases will lead to another state in which the data in these database(s) are still 
correct. This turns out to be not trivial, especially for complex update operations, 
the so-called transactions. It is even more complicated in settings of more than one 
database system, i.e., in DB" architectures. 
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Transaction management guarantees data integrity and especially data Consistency 
through Atomicity, Isolation, and Durability of any transaction (ACID conditions). 
Atomicity guarantees that either all of the tasks of a transaction are performed or 
none of them are; isolation makes intermediary updates of data inside the transaction 
invisible; and durability stands for persistence of the transaction’s results. 

The “2-phase commit protocol” was developed for transaction management in 
DB? architectures. Among other things, this protocol is intended to ensure data con- 
sistency in case of data redundancy. In the initial phase, it checks if the transaction 
can be carried out by all affected application systems. Only if the changes are pos- 
sible everywhere, they are actually carried out in a second phase in all application 
systems. To carry out the protocol, the application systems must be tightly coupled 
by synchronous communication, and the database schemata of all involved database 
systems must be known. For an application system in a health information system, 
this means that an interface must be provided where both updates and the cancella- 
tion of these updates are possible. This is not the case for commercial application 
components available today. Generally, the individual database schemata of each 
component are also not known. Due to these reasons, the 2-phase commit protocol 
to ensure data consistency has usually not yet been implemented within DB” archi- 
tectures of health information systems. 

Nevertheless, to guarantee data consistency, the following more asynchronous 
approach is typically chosen within a health information system: 

For every redundantly stored entity type, one application component is determined 
as the primary application system for this entity type. Thus, data on entities of this 
type can only be inserted, deleted, or changed in this primary application system. For 
example, the patient administration system is typically the primary application system 
for the entity types “patient” and “case.” Consequently, data on patients and cases can 
be created, deleted, or changed only in the patient administration system. Therefore, 
this application system is sometimes called the “leading system.” 

Transactions in a database of the primary application system are carried out 
without regard to whether the corresponding operations can also be (immediately) 
carried out in the databases of the other affected application components. Patient 
admission is thereby carried out through the patient administration system indepen- 
dent of, for example, what is going on in the R/S. It may happen that the R/S is not 
capable of inserting corresponding data on the patient or the case that were sent by 
the patient administration system into its database at the same point in time. The RIS 
is then obliged to catch up on database operations at a later point in time. 


3.9.2 Communication Server 


A quite simple way of communication between application systems is the asynchro- 
nous exchange of messages. Asynchronous communication means that the applica- 
tion system sending a message will continue its tasks without interruption even 
when awaiting a response message from the communication partner. Message 
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exchange generates queues of messages that have to be managed. Besides direct, 
point-to-point communication between two application systems, tools for managing 
message queuing can also be used. These so-called queue managers support the 
sending of messages from the sender to the receiver and the distribution of a single 
message to numerous receivers (multicasting). 

In health information systems, queue managers are typically referred to as com- 
munication servers. A communication server is an application system standing at 
the center of the logical tool layer of a health information system (Fig. 3.31). This 
architectural principle is also called star architecture (Sect. 3.6.4) and can be found 
in many health information systems. 

Generally speaking, a communication server is an application system used for 
the asynchronous receiving, buffering, and sending of messages. It can also be used 
to transform messages and monitor the traffic between application systems and may 
provide intermediate storage of messages in case the intended recipient of the mes- 
sages is not yet available (e.g., system down). An application system can send a 
message to the communication server over its communication interface. The com- 
munication server will then relay the message to one address or many addresses 
(multicasting) when these application systems are ready to receive. In the mean- 
time, the communication server buffers the sent messages in a queue (message 
queuing). In the case that the receiving application system is awaiting messages in 
a format based on a different interoperability standard than the sending application 
system sends, the communication server can transform the sent message. The appli- 
cation systems have to provide communication interfaces for sending messages to 
the communication server and to receive messages from it. 

In this way, the communication server is a tool to support data integration in a 
health information system of (DB", AC") architecture. Furthermore, communication 
servers prevent (DB", AC") styled health information systems from spaghetti archi- 
tectures and support CP! architectures. Application components can be more easily 
exchanged, thus supporting the expandability of the health information system’s 
architecture. 

Some communication servers may also provide synchronous communication. 
For this, the sending application system will pause from the time that it sends a mes- 
sage to the time that it receives the respective answer. In this way, communication 
servers can be used to invoke services as described in Sect. 3.9.4 and to provide 
feature integration as well. 

In health information systems with DB” architecture and redundant data storage, 
the application components store the data needed for supporting their functions by 
themselves. This holds especially for data on the entity types “patient” and “case.” 
Consequently, the communication server is used to ensure that every application 
system will find these data in its database system whenever the data is needed with- 
out having to request this data from the patient administration system. The follow- 
ing example describes how the patient administration system and the communication 
server can be integrated based on asynchronous communication and use of the 
interoperability standard HL7 (Sect. 3.7.2.1) in order to ensure data integration as 
well as data consistency regarding the entity types “patient” and “case”: 
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Fig. 3.31 Architectural style with multiple application systems, each with its own database sys- 
tem, using 3LGM? symbols. A communication server links the application components 


Mr. Russo has just been admitted to Ploetzberg Hospital in the administra- 
tion unit. Since the patient administration system is the primary application 
system for the entity types “patient” and “case,” patient admission is exclu- 
sively supported by the patient administration system (Sect. 3.9.1). Even before 
Mr. Russo leaves the administration unit to go to the cardiology ward, the fol- 
lowing messages are exchanged between the application systems (Fig. 3.31 
highlights steps 2 and 3): 


1. The patient administration system creates a message that indicates that Mr. 
Russo was just admitted to Ploetzberg Hospital (event called “A01” by HL7). 
This message includes data on the entity types “patient” and “case” using a pre- 
defined standard (such as HL7). 

2. The patient administration system sends this message to the communica- 
tion server. 

3. The communication server multicasts this message to all application systems 
that may need data on the entity types “patient” and “case” during the Mr. 
Russo’s stay (e.g., CPOE system, EHRS, RIS). Usually, nearly all application 
systems of health information systems need this administrative data. 

4. All application components receiving the message will store the data on the 
entity types “patient” and “case” for Mr. Russo in their own database system in 
order to have them available in case they are needed. 


A similar process takes place when administrative data on Mr. Russo is updated. 
If his address changes, for example, this is first documented in the patient adminis- 
tration system. This application system then sends a message on this update to the 
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communication server (2) that multicasts this message again (3), as described above. 
Since the patient administration system is the primary application system of patient 
and case, all updates of related data must be performed using the patient administra- 
tion system. 

By following these processes, data consistency is provided and application sys- 
tems will have actual data available in case they are needed. Above all, users in the 
radiology department, for example, can always find the administrative data on their 
patients in their RZS without the RIS having to make a request to the patient admin- 
istration system beforehand. 


3.9.3 Open Platforms and Vendor-Neutral Archives 


An application system is called open platform if it stores patient data based on open 
specifications and open information models and provides open Application 
Programming Interfaces (API) for storing and querying these data. “Open” in this 
context means that the specifications, information models, and interfaces are pub- 
lished and can be used by any vendor. 

An open platform follows the idea that both data and metadata are stored in a 
centralized database, with strict separation between application logic and data 
storage. 

The advantage of the open platform approach is that other application systems 
with different functionalities from different vendors can directly work on the same 
database (DB! architecture). This facilitates both data integrity (Sect. 3.5) and data 
integration (Sect. 3.8.1) even in V” architectures. The interoperability standard 
openEHR (Sect. 3.7.2.8) provides a universal, agreed-upon information model. 

Open platforms were first used in medical image archives and PACS, then typi- 
cally called vendor-neutral archives (VNAs). 

For example, after admitting Mr. Russo to the cardiology ward, blood samples 
have to be analyzed at the laboratory and radiological images have to be taken. 
Using an open platform as in Fig. 3.24, the LIS and the RIS would be able to access 
the same database as the patient administration system even if they are from differ- 
ent vendors. 

To support communication between open platforms and other application sys- 
tems, standards such as HL7 FHIR, DICOM, or IHE profiles are used (Sect. 3.7.2). 

While an open platform may seem difficult to introduce in a long-grown environ- 
ment of different application systems with their own proprietary information mod- 
els, it reduces the ever-increasing cost of mappings on the communication server 
side whenever a new application system is introduced. It also eliminates costly map- 
ping processes when migrating patient data from a previous to a new application 
system. Open APIs also enable new vendors to integrate their application software 
products in given information systems by using the agreed information models and 
thus enable a growing “application ecosystem.” 
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Service-oriented architectures (SOAs) represent architectural styles of health infor- 
mation systems that provide the means and tools to use services for the collabora- 
tion of application systems. A service is an encapsulated feature provided by an 
application system in order to be invoked by other application systems (Sect. 2.9). 

This results in synchronous communication between application systems, mean- 
ing that the process in the invoking application system, after starting the communi- 
cation with the providing application system, is paused until a response from the 
partner is obtained. 

The patient administration system may, for example, store data on the entity type 
“patient” and may provide a service for retrieving name, birthdate, and address of 
certain patients. In this case, the patient data is called a resource. Other application 
systems can access this resource by invoking the retrieve service and handing over 
a certain PIN. They will then obtain the desired data—if access is granted. Another 
service may be provided by application systems allowing a message to be sent to 
these application systems by invoking this service and handing over the message. 

Therefore, this technology is very good at achieving data integration and ensur- 
ing data integrity. In particular, it facilitates the construction of DB! architectures 
using VNAs. 

Moreover, the patient administration system could provide a service for patient 
admission. The RIS could thus invoke this admission service, handing over data on 
a certain person who should be admitted to the health care facility. As a result, the 
patient administration system executes all necessary actions needed to perform 
patient admission. With such more complex services, feature integration can be 
achieved in addition to data integration. 

When using World Wide Web technology, the resources are identified by certain 
Uniform Resource Identifiers (URIs). Application systems can provide basic ser- 
vices for GET, PUT, POST, and DELETE operations on their resources by offering 
the so-called RESTful APIs. For health information systems, resources as well as 
services for operating on the resources are standardized by FHIR (Sect. 3.7.2.3). 


3.10 Physical Tool Layer 


Application components are logical tools, and they cannot exist without physical 
tools as a basis. In an information system, we can describe this basis with the physi- 
cal data processing systems at the physical tool layer. As stated earlier, physical data 
processing systems can be human actors, non-computer-based physical tools, or 
computer systems. 

If application components that exchange data and interact with each other are 
installed on different physical data processing systems at the physical tool layer, 
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these physical data processing systems have to communicate as well, i.e., integra- 
tion is also needed there. 

We will now have a closer look at typical computer-based physical data process- 
ing systems and their integration. You will learn about physical interoperability and 
integration and how challenges in terms of availability and security of application 
systems and data are addressed in the design of communication networks and the 
construction and operation of data centers. 


3.10.1 Physical Data Processing Systems 
3.10.1.1 Servers 


Servers are used to provide sophisticated features to clients (Sect. 3.10.1.2). Servers 
can run databases (database server), they can run the back-end part of application 
software products (application server), or they can support printing (printer server). 
Terminal servers run the front-end part of application software products, which tra- 
ditionally have been implemented on and run by clients. If terminal servers are used, 
mere terminals (Sect. 3.10.1.2) for displaying output and receiving input are suffi- 
cient. Further server types are name servers (for domain name system (DNS) man- 
agement), DHCP servers (for dynamic IP assignment), mail servers (for email 
services), and web servers (for website management). 

There is a strong trend to virtualize servers. A “real” (i.e., physical) server can 
simulate lots of the so-called virtual servers. Every virtual server runs a particular 
instance of an operating system and can be used to implement application software 
products. Thus, these virtual servers behave nearly identical to physical servers. This 
approach makes computing power in a data center much more flexible and scalable. 

Virtual servers also result from coupling physical servers in order to maximize 
availability through redundancy. These kinds of coupled servers are called a server 
cluster. It makes sense to localize the members of the cluster at different sites of the 
data center (Sect. 3.10.3). 


3.10.1.2 Clients and Personal Devices 


Clients comprise all data processing tools that are immediately available to the vari- 
ous user groups within a hospital, for example: 


e stationary personal computers (PCs) located at defined places in a health care 
facility (e.g., the PC in the ward office), 

e terminals (also called thin clients) which have only functionalities for displaying 
and for data entry but have no storing capability, 

e mobile computers such as laptops, tablets, or smartphones used for mobile infor- 
mation access. 
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Mobile devices are especially important in health care settings because devices 
must provide both data and support of functions wherever patients are. This applies 
not only to health care facilities, but especially to the patient’s home environment. 

In medicine, there is a plethora of other personal devices in use to capture data 
from and about individuals, making it available for further processing in application 
systems. Sensors for recording vital signs such as heart rate, blood oxygen satura- 
tion levels or an ECG are not only used in the ICU of a hospital. Smartphones and 
smart watches also have such sensors and can provide corresponding data. These 
personal devices also provide sensors for personal identification, such as finger- 
printing or retinal eye scanning. Smart cards, which are connected via special read- 
ers, are also used for identification. 

Overall, large health care facilities such as a 1500-bed university medical center 
will have about 4000 clients (PCs) and 3000 mobile devices. This causes not only 
investment costs, but also enormous maintenance costs. The energy consumption of 
these devices is also considerable. 

If we assume a power consumption of approx. 300 watts for one PC, this results 
in a total consumption of approx. 1.2 MW (megawatts) for all PCs together. The 
mobile devices’ energy consumption must be added. 


3.10.1.3 Storage 


Health information systems must store not only large amounts of data but also very 
important data that may be crucial for the patients’ health and life. This requires 
storage devices of high capacity and high reliability. The storage media that are used 
range from magnetic discs for random access to magnetic tapes and optical media 
for backup and archiving. 

Storage devices, regardless of the media used, are not specifically attached to and 
exclusively used by certain servers. Moreover, storage area networks (SANs) pro- 
vide storage services of different kinds to all servers integrated in this network. This 
technology allows the storage capacities to be scaled up or down quite easily 
depending on actual storage needs. Additionally, SANs help to maximize availabil- 
ity through redundancy. It makes sense to localize the members of an SAN at differ- 
ent sites of the data center (Sect. 3.10.3). 


3.10.2 Physical Interoperability and Integration by 
Communication Networks 


The types of integration introduced in Sect. 3.8 relate to the logical tool layer and, 
more precisely, to sets of application systems. Let us supplement this catalog of 
integration types with physical integration. 

Physical integration refers to a set of physical data processing systems and is 
guaranteed if the necessary physical communication is possible for each required 
data exchange. This requires having only one computer, for example, a mainframe, 
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hosting all application systems or having physical interoperability of the physical 
data processing systems to be connected. For this, the devices must have hardware 
interfaces for data exchange. In other words, physical interoperability of physical 
data processing systems is a prerequisite for technical interoperability of application 
systems that are installed on different physical data processing systems (Sect. 
3.7.1.1). In other words, physical integration between physical data processing sys- 
tems is a prerequisite for any kind of integration between application components. 

Communication networks can be implemented by optical fibers, copper cables, 
and wireless LAN technologies. Different communication protocols such as 
Ethernet or Token Ring can be used. 

The ISO/OSI reference model provides a framework for describing communi- 
cation between computers at seven levels. Standards for the respective communi- 
cation protocols are available for each level. With respect to the three-layer 
graph-based metamodel (3LGM?), these seven levels interconnect the physical 
with the logical tool layer of a health information system. Level 7 may be consid- 
ered the logical tool layer which corresponds to the name of the communication 
standard HL7 (Sect. 3.7.2.1). A set of protocols for each of the seven levels is 
called a protocol stack. 

In order to be able to use the mobile devices required in medicine, appropriate 
wireless networks are necessary. Wireless local area networks (WLAN) are com- 
monly used inside buildings, both in health care facilities and in private environ- 
ments. Outside buildings, for example to connect ambulance vehicles but also to 
feed a limited campus of a health care facility, the same mobile networks that are 
also used for mobile telephony are used. Currently, fifth-generation mobile net- 
works (5G) are being introduced. These enable high data transmission rates but 
require a close-meshed network of antennas. The health effects of the associated 
electromagnetic fields are subject to controversial debate. 

The network that exclusively connects the physical data processing systems of a 
facility is also called intranet. Extensive security measures are required at the inter- 
face between the intranet and the internet to prevent unauthorized access to the 
physical data processing systems within the intranet from outside the facility. These 
include, in particular, the so-called firewalls. Firewalls are physical data processing 
systems on which incoming and outgoing communication is monitored by software. 

To optimize security, the intranet itself is also partitioned into further security 
zones. Depending on the need for protection and the permitted user group of appli- 
cation systems, the physical data processing systems on which these application 
systems are installed are assigned to such security zones. Communication into and 
out of a security zone is also monitored using dedicated hardware. 


3.10.3 Data Centers 


The servers must fulfill special requirements related to availability, stability, perfor- 
mance, maintainability, and redundancy. For health care facilities, this can only be 
economically achieved if the servers are centralized in a data center. 


142 3 Technological Perspective: Architecture, Integration, and Standards 


The reliability of the data center, with all its equipment and physical data process- 
ing systems, is the very basis for the reliability of the health information system as a 
whole. Although system stability of application components deals with the quality of 
the software used, system stability must be enhanced by redundancy. Redundancy is 
not needed at the logical tool layer, however, but at the physical tool layer. 

This requires data centers that provide at least two redundant sites as well as mir- 
rored servers and storage devices at each site, a stable energy supply, high-capacity 
air conditioning, server rooms that are burglar-proof and disaster-proof, and effec- 
tive means for fire protection. Even if an information management department 
ensures an effective backup, the continuous operation of the data center through 
appropriate redundancy is of utmost importance. 

Data center staff needs software tools for supervising proper operation of serv- 
ers, communication network components, PCs and terminals, and the application 
components running on top of these physical tools. 

For two redundant sites of the data center housing the servers of a large academic 
center, one must expect an energy consumption of 0.5 MW. This energy consump- 
tion results not only from the power consumption of the servers but also from the 
energy requirements of the air conditioning systems, which must dissipate the elec- 
trical energy converted into heat. Consideration should therefore be made as to 
whether the waste heat from the computers can be used for other useful purposes 
such as heating the facility’s domestic water. 

These and the previously mentioned figures on client energy consumption alone 
make it clear that medical informatics specialists, and information managers in par- 
ticular, not only have responsibility for good information systems but also for the 
impact of information systems on the global climate. 

Not only the high energy consumption, but also the major technical challenges 
involved in operating a data center, suggest that smaller health care facilities in par- 
ticular should consider whether servers in the cloud, and thus commercial data cen- 
ters, can be used instead of own data centers. However, this requires stable and 
sufficiently powerful communication links. In addition, the data protection regula- 
tions of the respective country must be observed. Conversely, large health care facil- 
ities can consider whether their own data center can be offered to smaller surrounding 
facilities for use. The large facility could then become a cloud provider for the 
smaller facilities. 


3.10.4 Data Security 


Data security means protecting the data of an information system both from destruc- 
tion and loss and from illegal use by unauthorized persons. This is particularly 
important in health information systems for two reasons. Firstly, health data is highly 
sensitive and represents intimate information about individuals that must never fall 
into the hands of third parties without the consent of the individuals concerned. 
Secondly, a health care facility is at risk of becoming completely incapacitated if the 
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data in the patients’ health records can no longer be accessed. This can cost lives. 
Recent cases of the so-called ransomware attacks on hospitals, for example, illus- 
trate the associated dangers. In ransomware attacks, data is encrypted by criminals 
and a key for decryption is only made available after payment of a ransom. 

It is therefore imperative to invest in protective measures at all levels. For exam- 
ple, as mentioned above, communication networks must be protected through their 
structure and suitable hardware and software, data backups must be performed and 
the data copy must be protected against attacks, and highly qualified personnel must 
be available. We can only hint at the required know-how in this textbook and there- 
fore refer to the relevant, current technical literature and the training and continuing 
education programs on data security. 

In health care facilities, it is the responsibility of the management of information 
systems to ensure data security, while corporate management must provide the nec- 
essary financial resources for this purpose. 

In the private environment, this responsibility lies with the individuals them- 
selves. It is the task of politics, but also of the professional societies for medical 
informatics, to ensure that people are informed, educated, and advised. 


3.11 Examples 


3.11.1 A Reference Model for the Domain Layer 
of Hospital Functions 


The reference model for the domain layer of hospital information systems consists 
of the subset of functions and entity types described in Sects. 3.2.3 and 3.3 that are 
relevant for hospitals. The reference model focuses on the activities in patient care. 
Thus, the main enterprise function is patient care, and there are maintenance func- 
tions supporting patient care such as supply management, scheduling and resource 
allocation, hospital administration, hospital management, and research and teach- 
ing (Fig. 3.32). 

Furthermore, the enterprise functions in that reference model bear a relation to 
each other by entity types which they can update or interpret. To define entity types 
within the reference model of the domain layer, the HL7-RIM®? was used. 

The Reference Model for the Domain Layer of Hospital Information Systems is 
available as a 3LGM? model’ and for this reason can be immediately used for mod- 
eling hospital information systems. Following the definition of reference models in 
Sect. 2.13, the Reference Model of the Domain Layer can be used as a model pat- 
tern for the domain layer of hospital information systems and, additionally, can help 


Shttp://www.hl7.org/Library/data-model/RIM/modelpage_mem.htm. 


®http://www.3lgm2.de//Modelle/Referenzmodelle_und_Beispielmodelle/RM_DomainLayer_ver- 
sion2_English.z3lgm. 
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to compare hospital information systems by means of a uniform terminology used 
for the domain layer. This means that, for each enterprise function of the Reference 
Model of the Domain Layer, it is possible to determine the support by application 
components in different information systems. 


3.11.2 The Domain Layer of CityCare 


CityCare is a health care network in the city where Mr. Russo and his family live. In 
CityCare, Ploetzberg Hospital, Ernst Jokl Hospital, and a specialist medical office 
for sports medicine cooperate in order to treat patients suffering from joint injuries. 

Mr. Russo’s son, an amateur football player, injured his knee joint during his last 
match. Patients suffering from joint injuries first consult CityCare’s primary care 
sports physician. If the physician suspects that surgery is needed, she orders MRI 
diagnostics at Ploetzberg Hospital. After receiving the findings from Ploetzberg 
Hospital, the sports physician admits patients needing arthroscopic surgery to Ernst 
Jokl Hospital for further treatment. 

Figure 3.33 describes the domain layer of the CityCare scenario. Functions intro- 
duced in Sect. 3.3 were used and specialized or decomposed to model the domain 
layer. The entity types used are described in Sect. 3.2. 
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Fig. 3.33 Domain layer of CityCare 
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All three health care facilities cooperating in CityCare perform activities regard- 
ing the functions of patient admission and execution of diagnostic and therapeutic 
procedures. These functions performed by each health care facility are modeled 
only once at the domain layer. Ploetzberg Hospital is the only hospital offering 
“execution of MRI diagnostics,” whereas Ernst Jokl Hospital is the only hospital 
offering “execution of arthroscopic surgery procedure.” 

Entity types such as “patient,” “case,” and “order” that are used or updated in all 
three facilities are also modeled once at the domain layer. To visualize different 


health care facilities, labels (see grey rectangles) were used in the 3LGM? model. 


3.11.3 The Logical Tool Layer of CityCare 


At the logical tool layer shown in Fig. 3.34, the application systems that are relevant 
for the described scenario in CityCare and their communication are modeled. For a 
better overview, the institutional information systems and the jointly used applica- 
tion systems of the network are labeled by gray rectangles. 

The specialist medical office has one application system that is used for patient 
administration and medical documentation. Both Ploetzberg Hospital (PH) and 
Ernst Jokl Hospital (EJH) have their own patient administration system and 
MDMS. These are different installations of different application software products 
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Fig. 3.34 Logical tool layer of CityCare 
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which are therefore modeled as single application systems. For MRI diagnostics, 
Ploetzberg Hospital additionally uses an RIJS and an MRI scanner which is also 
modeled as an application system. Images that are generated by the MRI scanner 
and all other medical and administrative data from the MDMS, the RIS, and the 
patient administration system are stored in the Vendor-Neutral Archive PH, an open 
platform. Thus, these other application systems do not need their own database 
systems. All three facilities access the central EHR system, a clinical information 
system, of the health care network. This EHR system comprises patient information 
such as diagnoses, findings, and discharge letters received from all facilities. To 
manage the PINs from the different facilities, the health care network uses an MPI 
that assigns a transinstitutional PIN for the patients and maps the different PINs of 
the facilities to this transinstitutional PIN. This is a precondition for being able to 
build the EHRS in the health care network. 

The matrix view in Fig. 3.35 shows which functions are supported by which appli- 
cation systems in CityCare. The application system of the specialist medical office, 
for example, supports six different functions. We can also identify functional redun- 
dancies. For administrative admission, for example, all three facilities use different 
application systems. Within a health care network like CityCare, it would also be 
possible to support this function with one application system that is used by each facil- 
ity. Application systems serving solely as an integration technology, such as the EJH 
communication server, do not need to be linked with functions at the domain layer in 
3LGM? models. For the VNA and the EHR system, no supported functions are mod- 
eled either—finding appropriate functions is part of the exercise in Sect. 3.12.6. For 
the correctness of the model, application systems are only assigned to “leaf functions” 
but not to superordinate functions such as “execution of MRI diagnostics.” 
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Fig. 3.35 Matrix view visualizing the relations between functions and application systems in 
CityCare 
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The architecture of Ernst Jokl Hospital (in the left of Fig. 3.34) can be described 
as a star-based (DB", AC”, V”) architecture. There are at least two major application 
systems (AC"), probably from different vendors (V"), with their own respective 
database system (DB"). The application systems—the patient administration system 
and the MDMS—exchange data via a communication server (star-based architec- 
ture) using HL7 V2 messages. Ploetzberg Hospital also features a star-based archi- 
tecture which is, however, different from Ernst Jokl Hospital’s architecture. At the 
center of Ploetzberg Hospital’s (DB', AC", V") architecture, there is a VNA imple- 
mented as an open platform based on uniform information models in the openEHR 
standard. The hospital’s interoperability experts control these information models 
and stipulate and enforce their use whenever a new vendor system is added. The RIS 
at Ploetzberg Hospital’s radiology department communicates with the MRI scanner 
using the DICOM standard. The DICOM images generated by the MRI scanner as 
well as the radiological reports that are documented with the help of the R/S are 
stored in the VNA. 

The institutional information system of the specialist medical office has a (DB', 
AC!, V!, C”) architecture because it only consists of a single application system with 
one database system. The application system combines the functionalities of a 
patient administration system and an MDMS. It could therefore be regarded as the 
CIS (or EHRS) of a medical practice (Sect. 3.4.15). This comprehensive application 
system sends orders for radiological examinations or orders for surgical procedures 
to Ploetzberg Hospital or Ernst Jokl Hospital, respectively. For this, it uses the HL7 
V2 standard. 

All three care facilities work together in the CityCare health care network, which 
provides a centralized EHRS that can receive as well as provide patient EHR data on 
demand. For data persistence, the central EHRS implements the openEHR standard 
for highly structured EHR data and an additional database system for documents. To 
receive patient data, the EHRS provides different interfaces for the three facilities in 
the network: an HL7 FHIR interface for Ernst Jokl Hospital’s communication 
server, an HL7 V2 interface for the specialist medical office, and a native openEHR 
interface for Ploetzberg Hospital. For cross-network identification of patients, the 
CityCare network has implemented an MPI based on an IHE integration profile. In 
the future, it is planned to implement a portal both for external physicians and for 
the patients themselves so they can access their data in the central EHRS. 

If Mr. Russo presents at Ernst Jokl Hospital, the local physician will look for 
available information on Mr. Russo in the hospital’s MDMS. The system can then 
send a query to the CityCare network, asking for available information on Mr. 
Russo. The query is sent via Ernst Jokl Hospital’s communication server to the net- 
work’s central EHR system using the unique PIN for Mr. Russo. The central EHR 
system sends back Mr. Russo’s data using the HL7 FHIR standard to the Ernst Jokl 
Hospital communication server and the data is forwarded to the EJK MDMS. 
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3.11.4 The Physical Tool Layer of CityCare 


At the physical tool layer of CityCare, parts of the data centers of Ploetzberg 
Hospital and Ernst Jokl Hospital as well as a joint data center of the health care 
network are modeled (Fig. 3.36). The specialist medical practice only houses three 
PCs on which the patient management and MDMS can be used. The application 
system is installed on an application server which is hosted by Ernst Jokl Hospital’s 
data center. Both hospitals also host application servers on which the application 
systems of the respective hospitals are running. For storing data, SANs are used. In 
the data center of the health care network, there is an application server for the 
EHRS and another server for network management. 

The relations between the logical tool layer and the physical tool layer are visual- 
ized by a matrix view (Fig. 3.37). The specialist medical practice only houses three 
PCs on which the patient management and MDMS can be used. The application 
system is installed on an application server which is hosted by Ernst Jokl Hospital’s 
data center. Both hospitals also host application servers on which the application 
systems of the respective hospitals are running. For storing data, SANs are used. In 
the data center of the health care network, there is an application server for the 
EHRS and another server for network management. 
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Fig. 3.37 Matrix view visualizing “installation” relations between application systems and physi- 
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3.12 Exercises 
3.12.1 Domain Layer: Differences in Hospital Functions 


Look at the functions presented in Sect. 3.3.2. Now imagine a small hospital (e.g., 
350 beds) and a large university medical center (e.g., 1500 beds). What are the dif- 
ferences between these hospitals with regard to their functions? Explain your answer. 


3.12.2 Domain Layer: Different Health care Professional 
Groups and Health care Facilities 


Look at the functions listed in Sect. 3.3.2. Look at the relationships between the 
functions and the different health care professional groups (physicians, nurses, 
administrative staff, others) working in hospitals and medical offices. Select one 
health care professional group and describe which functions are most important for 
this group. 


3.12.3 Domain Layer: The Patient Entity Type 


Look at the entity type “patient” that is interpreted and updated by various func- 
tions. Which functions update the patient information, which functions interpret it? 
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3.12.4 Logical Tool Layer: Communication Server 


Imagine a hospital information system that comprises four application systems: a 
PAS, an MDMS, a RIS, and a PDMS. The hospital is now considering the introduc- 
tion of a communication server to improve data integration. Discuss the short-term 
and long-term pros and cons of this decision. Which syntactic and semantic stan- 
dards could be used? 


3.12.5 Logical Tool Layer: Integration from the User’s 
Point of View 


During a night shift, a nurse uses the patient administration system to conduct the 
administrative patient admission. The nurse then uses the NMDS to plan nursing 
care. Now consider the types of integration presented in Sect. 3.8 and discuss how 
this nurse would recognize a high (or low) level of data integration, semantic inte- 
gration, user interface integration, context integration, feature integration, and pro- 
cess integration. 


3.12.6 CityCare 


The following questions can be answered by reading the text and analyzing the 
3LGM? figures of the CityCare Example 3.11. 


(a) The EARS and the VNA in CityCare are not linked with any function they sup- 
port. Which function of the domain layer may (partly) be supported by these 
application systems? Which functions (as introduced in Sect. 3.3) that are sup- 
ported by these application systems could be added at the domain layer? 

(b) In which database systems shown in the logical tool layer (Fig. 3.34) should the 
entity type “patient” be stored? 

(c) The MPI should receive messages containing PINs (entity type “patient”) from 
all patient administration systems. Why is there no communication link between 
the MPI and the patient administration system of Ernst Jokl Hospital? 

(d) According to the matrix view, which functions are supported redundantly in 
CityCare? Discuss pros and cons of the functional redundancies in this sce- 
nario. What redundancies would you resolve and how? 

(e) Which functions in which health care facility cannot be performed anymore if 
“Application Server 1 Ernst Jokl Hospital” fails? Suggest a change to the physi- 
cal tool layer that would minimize the risk of missing function support in case 
a single application server fails. 

(f) For the CityCare network, would it make sense to implement further profiles 
from IHE? Explain your decision. 
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Chapter 4 A) 
Management Perspective: Scopes K 
and Tasks of Managing Health Information 
Systems 


4.1 Introduction 


In Chap. 3, we discussed the technological perspective of health information sys- 
tems. We will now examine how health information systems have to be managed so 
they will fulfill the requirements of the stakeholders as presented in Sect. 1.3. 

As already introduced in Sect. 2.12, management of information systems ensures 
systematic information processing that supports information and knowledge logis- 
tics and therefore contributes to the health care setting’s goals. High-quality health 
information systems and their components can only by achieved if the health infor- 
mation systems are systematically planned, monitored, and directed. 

Management of information systems can be differentiated into strategic, tactical, 
and operational management of information systems. In this chapter, we will first 
discuss these three scopes of management of information systems and how they are 
interlinked in more detail. We will then focus in more detail on strategic manage- 
ment of information systems and discuss tasks and methods of strategic planning, 
strategic monitoring, and strategic directing of health information systems. We will 
also discuss organizational structures for systematic management of information 
systems. 

Finally, it is important to remember that for the management of information sys- 
tems we can only say in a few cases what is indeed right and what is wrong. Rather, 
in practice, decisions must be made again and again as to which solutions and 
approaches are best suited in the respective setting (Fig. 4.1). In doing so, a balance 
must be reached between at times conflicting goals. This balancing act is what the 
last section is about. 


© The Author(s) 2023 153 
A. Winter et al., Health Information Systems, Health Informatics, 
https://doi.org/10.1007/978-3-031-12310-8_4 


154 4 Management Perspective: Scopes and Tasks of Managing Health Information Systems 


Fig. 4.1 Health information systems constitute an essential part of providing good health care. 
Managing health information systems requires both professional skills and communication 


After reading this chapter, you should be able to 


e define management of information systems and explain the differences between 
strategic, tactical, and operational management of information systems, 

e describe the tasks of strategic planning, monitoring, and directing of health infor- 
mation systems, 

e describe the tasks of tactical and operational management of health information 
systems, 

e discuss appropriate organizational structures for the management of information 
systems in health care settings, and 

e explain examples of balancing priorities in strategic management of health infor- 
mation systems. 


Please note that the terms highlighted in italics are terms from the glossary or 
represent functions or application system types. 


4.2 Dimensions of Managing Health Information Systems 


In this section, we present in more detail the tasks of managing health information 
systems in health care facilities. We will discuss strategic, tactical, and operational 
management, their goals, and their tasks. 
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As already discussed in Sect. 2.12, management of information systems encom- 
passes the management of all components at the three layers of an information 
system—the management of functions, processes, and entity types, of application 
components and services, and of physical data processing systems. We consider 
these components the objects of management of information systems. 

Although the layers help to structure management of information systems by 
objects, it is helpful to also divide management of information systems with regard 
to its scope into strategic, tactical, and operational management. 

Strategic management of information systems deals with the information system 
as a whole and establishes strategies and principles for the evolution of the informa- 
tion system. An important result of strategic management activities is a strategic 
information management plan. 

Tactical management of information systems deals with particular functions, 
application components, or physical data processing systems that are introduced, 
removed, or changed. Usually, these activities are done in the form of projects. 
Tactical information management projects are initiated by strategic management of 
information systems. Thus, strategic management of information systems is a vital 
necessity for tactical management of information systems. The result of tactical 
information management projects is an updated information system. 

Operational management of information systems is responsible for operating the 
components of the information system. It ensures the smooth operation of the sys- 
tem in accordance with the strategic management of information systems plan. 
Additionally, operational information management plans, directs, and monitors per- 
manent services for the users of the information system. 

Regardless of which objects are currently being processed and on which scope 
management of information systems is currently focused, management of informa- 
tion systems is always involved in the tasks of planning, directing, and monitoring. 

This results in three dimensions for classifying management of information sys- 
tems as shown in Fig. 4.2. When combining the three scopes, the three main tasks, 
and the three major objects of management of information systems, we can also 
define a 3 x 3 x 3 matrix of information management activities. 

This separation of activities of management of information systems is essential 
because each of the information management scopes has different perspectives and 
therefore uses different methods and tools. For example, planning within strategic 
management of information systems focuses on strategic information management 
plans. Planning within tactical management needs, for example, methods for project 
management or user requirements analysis, while directing within tactical manage- 
ment needs methods for software development or customizing. Operational man- 
agement requires methods and tools for topics that range from intra-enterprise 
marketing of services to service desk and network management. 

Strategic, tactical, and operational management depend on each other. Figure 4.3 
presents their relationships in a three-layer graph-based metamodel (3LGM7) 
domain layer. 
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Within strategic management of information systems, a strategic information 
management plan and project portfolios have to be created as a result of planning 
activities. Strategic planning depends on the business strategy of the enterprise, 
defined by the strategic enterprise management, on information from HIS quality 
indicators, and on legal regulations. Since the strategic information management 
plan contains a project portfolio to be performed in the coming years, strategic 
directing means initiating these projects. Strategic directing updates a project char- 
ter which is then processed by tactical management of information systems. Strategic 
monitoring collects various information regarding the state of the information sys- 
tem components and users’ and patients’ requirements and compares these with the 
strategic information management plan and the project portfolio. The resulting HIS 
quality indicators are fed back to strategic planning. 

Within each project of tactical management of information systems, the course of 
the project must be planned (project plan) and the project will be directed and moni- 
tored according to this plan. The result of a project are updated information system 
components. When a project ends, the result is documented in a handover protocol 
which is passed to operational management of information systems for further oper- 
ation of the information system component. 

Executive operational tasks (such as operating a computer server) are not part of 
information management. Nevertheless, these operational tasks must be planned, 
directed, and monitored. This is carried out by operational management of informa- 
tion systems. 

As already indicated in Fig. 4.3, management of information systems in health 
care facilities is performed in an environment full of influencing factors. Decisions 
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Fig. 4.3 3LGM? representation of the relationships between functions of “strategic, tactical, and 
operational management of information systems and related entity types” 


made by the strategic enterprise management of the health care facility directly 
influence management of information systems. For example, the decision of the 
strategic enterprise management of a health care facility to cooperate in a health 
care network will have an impact on the future state of the information system. New 
legal regulations also have an effect on the management of information systems. For 
example, a law enforcing the introduction of a new billing system based on patient 
grouping will require adaptations in application components. Patients and users, as 
important stakeholders of an information system, also influence management of 
information systems with their values, attitudes, and requirements. Patients may 
demand a patient portal to access some of their data from home, for example. Or 
management of information systems itself may affect the management of the health 
care facility. If, for example, management of information systems proposes the 
introduction of a multi-professional electronic health record system (EHRS), this 
must in turn lead to strategic activities such as process reorganization within the 
health care facility. 

Figure 4.4 summarizes these relationships between management and operation 
of a health information system and the influencing factors. 

We now look at the activities of strategic, tactical, and operational management 
of information systems in health care facilities. 
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Fig. 4.4 Strategic, tactical, and operational management of information systems in health care 
facilities and their relationships 


4.3 Strategic Management of Information Systems 


Strategic management of information systems deals with the information system of 
a health care facility as a whole. It depends on and must be aligned to the facility’s 
vision, mission, and strategic goals. 

Strategic management of information systems and its strategic information man- 
agement plan are the prerequisites for tactical and operational management of infor- 
mation systems in a health care facility. 

We will now discuss in more detail strategic planning, monitoring, and directing 
of management of information systems in health care facilities. 


4.3.1 Strategic Planning 


Strategic planning is the first step of a systematic strategic information management 
process and leads to a strategic information management plan as basis. 
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Planning, as part of strategic management of information systems, must translate 
vision, mission, and strategic goals into a specific strategic information manage- 
ment plan. Thus, the most important tasks of strategic planning are strategic align- 
ment of business goals and strategic information management goals, and the 
development of both a long-term strategic project portfolio as part of a strategic 
information management plan and annual project portfolios. 


4.3.1.1 Strategic Alignment of Business Goals and Information 
Management Goals 


The basis for strategic management of information systems in a health care facility 
is the mission of the facility. The mission describes what the basic functions of the 
facility are and what it stands for. For university medical centers in Germany, for 
example, it is stipulated by law that they must offer the basic functions of patient 
care, medical research, and teaching of future physicians. 

Strategic goals are concrete specifications of how this mission is to be fulfilled 
within a certain, usually longer, period of time. Such goals are set by the manage- 
ment of the facility. The strategic, long-term goals of a health care facility are also 
called business goals. The term “business goal” should not be understood in a purely 
profit-oriented or economic way, which means focusing on financial gain only. 
Instead, as health care facilities should serve the needs of individual patients and of 
society, we should understand business goals as all goals of a health care facility 
that reflect its mission in patient care, research, and education. 

Health care facilities aim to provide efficient, high-quality health care. They may 
thus define, for example, one or more of the following business goals as their stra- 
tegic, long-term goals: 


e offering holistic, interprofessional, patient-oriented care, 

e offering integrated care in close cooperation with external health care providers, 

e offering high-quality care for a special patient group (e.g., by specialized medi- 
cal competence centers), 

e attracting patients from other regions, 

e supporting clinical research and medical education (e.g., as university-affiliated 
hospital), 

e being very cost-effective, or 

e being an innovative and modern health care facility (e.g., by using up-to-date 
technology for clinical diagnostics). 


Different goals and sub-goals result in different information management strate- 
gies and different architectures of information systems. Also, advances in informa- 
tion and communication technology (ICT) may influence business goals. The role 
of management of information systems thus varies between two extremes. At one 
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extreme, management of information systems may be seen as a purely supporting 
function; that is, the business goals determine the information management plan- 
ning activities. This is called “organizational pull” and the person in charge of stra- 
tegic management of information systems needs to know the business goals of the 
health care facility. At the other extreme, management of information systems is 
seen as the strategic resource from which the health care facility gains competitive 
advantage. The application of technological advances mainly determines the further 
development of the health care facility and its position on the health care market. 
This is called “technology push.” For this, the top management needs to know the 
potential of information systems with regard to supporting or shaping the business 
goals. Strategic management of information systems must thus be able to offer this 
information to top management in adequate and understandable form. 

Strategic alignment describes the process that balances and harmonizes the busi- 
ness goals of the health care facility and the information management strategies to 
obtain the best results. Strategic alignment ensures that the strategic information 
management plan directly supports the business goals and that IT projects and IT 
budget can be directly tied to these business goals. 


4.3.1.2 Strategic Information Management Plan 


The strategic information management plan represents the long-term planning of 
the information system of a health care facility. This plan describes the business 
goals, the information management goals, the current state of the information sys- 
tem, the future state of the information system, and the steps to transform the cur- 
rent into the planned information system. Strategic management of information 
systems must create and regularly update this plan. The strategic information man- 
agement plan is the basis for all tactical and operational information management 
activities and is the precondition for systematically directing and monitoring the 
information system of a health care facility. 

Strategic management of information systems is an ongoing process, and there is 
no use in trying to solve all problems of information processing at the same time. 
Solely a stepwise approach, based on different levels of priorities, is feasible. The 
strategic information management plan is therefore the basis for a strategic project 
portfolio that describes projects or groups of projects, their priority, and a rough 
timeline for their initiation for the coming years. 

The long-term strategic information management plan is usually valid for a lon- 
ger period of time (e.g., 3-5 years). However, requirements (e.g., due to legal 
changes or new user requests) and resources (staff, money) may change more 
quickly than the strategic information management plan, or strategic monitoring 
results may require a faster adjustment or an update of prioritization of projects. 
This is reflected in the annual project portfolio (Sect. 4.3.1.3) that is annually 
derived from the strategic project portfolio. It lists the projects to be executed in the 
next year. 


4.3 Strategic Management of Information Systems 161 


The strategic information management plan should be written by the persons 
responsible for strategic management of information systems (e.g., the chief infor- 
mation officer (CIO)) and approved by the top management. Without proper strate- 
gic planning, it would be a matter of chance if the information system of a health 
care facility fulfilled strategic information goals. But considerable efforts have to be 
made for creating strategic plans. 

Figure 4.5 presents an overall view on strategic information management plan- 
ning and use. 

In larger health care facilities, several stakeholders are typically involved in the 
creation, updating, approval, and use of strategic plans, such as top management, 
clinical and administrative departments, service departments and information man- 
agement departments, staff members, funding institutions, consultants, or hardware 
and software vendors. 

These stakeholders may have different expectations of a strategic plan and are 
involved in different lifecycle phases for the following strategic plans: 


e creation, i.e., writing a first plan, 

e approval, i.e., making some kind of contract among the stakeholders, 

e deployment, i.e., asserting that the plan is put into practice, 

e use, i.e., the involved stakeholders (e.g., both the information management 
department and hardware and software vendors) refer to the plan when needed, and 

e updating when a new version is required (because of new requirements, new 
available technologies, failure to achieve individual tasks, or just leaving the time 
frame of the plan). After the first version, the creation and update phases merge 
into a cyclic, evolutionary development of the plan. 
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Fig. 4.5 Strategic information management planning of health care facilities. A “strategic infor- 
mation management plan” gives directives for the construction and development of an information 
system. It describes the recent and the intended information system’s architecture 
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Usually, the CIO, supported by the information management department, creates 
and maintains a proposal for the strategic information management plan. The CIO 
is interested in having clearly defined requirements for management of information 
systems. Top management is interested in the seamless and cost-effective operation 
of the health care facility. Top management approves the plans (probably together 
with the funding institutions). Employee representatives should be involved in elic- 
iting the requirements, as they will be using the resulting information systems. The 
current strategic plan will be used by the information management departments and 
the vendors of components when modifying the information system. External con- 
sultants may help to create the plan though they may also be engaged in negotiations 
for the approval of the plan. 

The most essential purpose of a strategic information management plan is to 
improve the information system so that it can best contribute to the business goals 
of the health care facility. This purpose should determine the structure of strategic 
plans; that is, it should show a path from the current situation to an improved situa- 
tion in which the business goals are achieved as far as possible and reasonable. 

A strategic information management plan thus should encompass the business 
goals, the resulting information management goals, the current state of the informa- 
tion system, and an assessment of how well the current information system fits the 
goals. Based on this assessment, the future state of the information system is 
described, together with a migration path represented by a strategic project portfolio 
that allows this future state to be reached. 

The strategic plan must also deal with the resources needed to realize the planned 
architecture and must include rules for the operation of the information system and 
a description of appropriate organizational structures. Examples of resources are 
money, personnel, software and hardware, rooms for servers and (paper-based) 
archives, and rooms for staff training. The resources should fit the architecture and 
vice versa. 

The general structure of strategic information management plans is described in 
the following paragraphs and is summarized in Fig. 4.6. It should be noted that this 
is only a basic structure which may be adapted to the specific requirements of a 
health care facility. 


1. Strategic goals of the health care facility (business goals) and of management 
of information systems: Based on a presentation of the business goals, the strate- 
gic information management goals are described based on strategic alignment. 

2. Current state of the information system: Before any planning starts, the infor- 
mation system’s current state is described. This may require some discipline 
because some stakeholders may be more interested in the planned (new) state 
than in the current (obsolete) state. The description is the basis for identifying 
those functions of the health care facility that are well supported by the informa- 
tion system and those functions that are not (yet) well-supported. Thus, applica- 
tion components and physical data processing systems are to be described, 
including how they support the functions. The metamodel 3LGM? (Sect. 2.14) 
and related software is very helpful for this task. 
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Fig. 4.6 Structure of a strategic information management plan 


3. Assessment of the current state of the information system: The current state 


is then assessed with respect to the achievement of information management 
goals. Note that the lack of computer support for a certain function may not in 
all cases be assessed as a sign of poor support for that function. For example, a 
lack of computers in patient rooms and, consequently, the use of paper-based 
documentation for clinical findings may be part of the goal of being a humane 
hospital without using computers and hand-held digital devices in this area. 
Chapter 5 will discuss further criteria to assess the quality of an informa- 
tion system. 

. Planned future state of the information system: Based on the assessment of 
the current state, a new state is described that achieves the goals better than the 
current state. Again, 3LGM? is useful here. The description of the planned state 
can be complemented by the description of the planned organizational structure 
of management of information systems. In many cases, this is an opportunity to 
introduce a CIO or to clarify his or her role. 

. Migration path from the current to the future state: This section describes a 
step-by-step path from the current to the future state. In the strategic information 
management plan, every such step is a project or a group of related projects 
(such a group is also called “program” in project management). The resulting 
migration path of projects describes priorities of projects as well as dependen- 
cies between projects. The resulting projects and their priorities can also be 
called a strategic project portfolio. This portfolio thus represents the migra- 
tion path. 
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A short management summary and appendices describing the organizational 
structure, personnel resources, the building structure, etc. are likely to complement 
a strategic plan. Section 4.8.1 presents as example the structure of the strategic 
information management plan of Ploetzberg Hospital. 


4.3.1.3 Annual Project Portfolio 


The annual project portfolio is derived from the strategic project portfolio as 
described in the strategic information management plan. While the strategic project 
portfolio represents the planned projects for a longer period of time (e.g., 3—5 years), 
the annual project portfolio describes the projects to be executed in the next year. 

The annual project portfolio thus contains a list of projects to be initiated in the 
next year together with their priorities, timeline, and rough resources. This annual 
project portfolio implements the long-term strategic project planning into an annual 
planning. It may reflect changes in prioritization of projects due to internal or exter- 
nal changes in the health care facility (e.g., a new data protection law or the avail- 
ability of a new mobile technology). The annual project portfolio must be approved 
by top management, which also provides the needed resources for all projects. 

An important instrument for building, managing, and updating annual project 
portfolios is portfolio management. Originating in the field of finance, the term 
portfolio management is today used in different management contexts. 

A portfolio is a collection of objects grouped together to facilitate effective man- 
agement of activities to meet strategic business objectives. Managing a portfolio 
comprises the selection and management of objects based on their value for the 
health care facility, but also based on their costs and risks and on their dependencies 
(i.e., one project can only start when another project has ended). Portfolio manage- 
ment establishes categories of objects (i.e., projects or application components) and 
defines priorities for each category (i.e., which projects should start first). Each 
category carries a different degree of risk and may thus need different project man- 
agement methods. 

In the context of management of information systems, portfolio management can 
focus on projects of information management or on components such as application 
components or physical data processing systems. 

Project portfolio management categorizes IT projects, among other things, 
according to their contribution to the business goals, their risks, and their expected 
costs. Based on prioritizing projects, project portfolio management allows for the 
planning and controlling of IT projects. A project portfolio is typically built when 
an organization defines or refreshes its strategic goals and its strategic information 
management plan. Both the final strategic project portfolio and the derived annual 
portfolio need to be authorized by the top management. To build a project portfolio, 
the following steps can be followed [1]: 
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1. Create an up-to-date list of ongoing or planned projects (e.g., take the strategic 
projects defined in the strategic information management plan or project from 
the annual project list). 

2. Define the evaluation criteria that will define the priority of each project (e.g., 
contribution of the project to major business goals, costs of the project, and risks 
of the project) and decide on the weight of each criterion. 

3. Evaluate each project against the evaluation criteria by collecting information 
from various sources (e.g., assess contribution to business goals based on assess- 
ment by the CEO, assess project costs from the project plan or IT budget, and 
assess risks of the project based on assessment by the project manager). 

4. Calculate an overall priority score for each project by using collected informa- 
tion and weight (e.g., multiply each evaluation score by the weight of each evalu- 
ation criteria and add the scores to get the overall priority score for a project). 

5. Select the projects with highest priority for execution in the next time period 
(e.g., selecting the most important projects to be initiated in the next year and 
thus to be included in the annual project list). Balance the number of selected 
projects with the available financial resources. 

6. Keep the project portfolio up to date on a regular basis (e.g., annually) by adding 
new projects or removing completed projects and by recalculating the priorities 
for the next annual project list. 


Unlike project portfolio management, application component portfolio manage- 
ment considers different types of components. For example, the portfolio proposed 
by the Gartner Group distinguishes three categories of application components: 
Utility applications are application components that are essential for the operation 
of the health care facility but have no influence on the business success and, there- 
fore, are independent of the business goals (e.g., the patient administration system). 
Enhancement applications are application components that improve the perfor- 
mance and thus contribute to the success of a health care facility (e.g., computer- 
based nursing management and documentation system (NMDS)). Frontier 
applications are application components that influence the position of the health 
care facility in the health care market (e.g., telemedical applications). Information 
management planning should aim at a well-balanced application portfolio—on the 
one hand, to efficiently support essential functions of the health care facility and, on 
the other hand, to not miss out on future technological innovations. 


4.3.2 Strategic Monitoring 


After having planned the information system strategically, one may expect that the 
information system will operate well in most of its functions, in most of its informa- 
tion processing tools, and in most parts of its operating organization. In many cases, 
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however, problems may occur. Confidentiality of data may not be assured in some 
circumstances; transmission of clinical reports may not be timely; adequate data 
integration capabilities may not be provided and thus consistency of redundant data 
may not be assured between application components; or, since there is no data ware- 
house, the health care facility may not be able to collect and analyze aggregated data 
to support patient care and operations. There may be additional problems to be 
taken into account at a strategic level. For example, users may be increasingly dis- 
satisfied with a specific application component, technical or motivational problems 
may lead to a decrease in documentation quality, increased documentation time may 
limit the time available for direct patient care, there may be an unforeseen amount 
of high effort for support and training, or the number of medical errors may rise due 
to software errors or unusable software. 

Besides low software quality, badly organized projects in tactical management of 
information systems or errors in strategic management of information systems may 
also lead to the problems described above. Such problems may become apparent 
very slowly, for example, when a formerly “good” component is not updated to 
match the overall technical progress, leading to inacceptable performance and func- 
tionality, or when more and more new application components need to be integrated 
into a spaghetti-styled architecture (compare Sect. 3.6.4). But problems may also 
arise very suddenly, for example, when a server suddenly crashes and no replace- 
ment is available or when, due to a software error, a wrong finding is presented to a 
patient, a physician makes a wrong decision, and the patient is harmed. 

Monitoring, as part of strategic management of information systems, means con- 
tinuously auditing quality and cost of the information system and assessing whether 
the strategic information management plan has been implemented as intended. 
Auditing determines whether the information system is able to fulfill its tasks effi- 
ciently, i.e., whether it contributes significantly to the facility’s vision and mission, 
meets the stakeholders’ requirements (Sect. 1.3), and fulfills the relevant laws. To 
allow auditing, monitoring needs to receive information from tactical management 
of information systems (e.g., on the successful completion of projects) and from 
operational management (e.g., on number of service desk calls) as well as informa- 
tion from users (e.g., from user satisfaction surveys) and from strategic manage- 
ment of the health care facility (e.g., on changes in the vision and mission). 
Additional information on the quality of the information system can be gained 
through evaluation projects. Monitoring results are used as input to direct tasks of 
management of information systems, which could, for example, initiate further proj- 
ects. Monitoring results will also give feedback to update the strategic information 
management plan, which could, for example, lead to further activities of strategic 
management. 

Typically, strategic monitoring comprises activities such as permanent monitor- 
ing activities, benchmarking, and ad hoc monitoring. These are explained in more 
detail in the following sections. 
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4.3.2.1 Permanent Monitoring Activities by Key Performance 
Indicators (KPI) 


An information system of a health care facility is typically too complex to allow all 
its components to be monitored at the same time. However, it is useful to define a 
subset of quality criteria that is to be monitored on a regular (daily, weekly, monthly, 
yearly) basis. Quantitative measurements for regular monitoring of the achievement 
of strategic goals are also called key performance indicators (KPIs). In general, 
KPIs are a set of quantitative and well-defined performance measurements that 
demonstrate how effectively an organization is achieving key objectives. KPIs not 
only allow areas of improvement to be identified but also help to compare own 
achievements to similar organizations (benchmarking). 

KPIs for information systems demonstrate how effectively key objectives of the 
information system, as typically defined in the strategic information management 
plan, are reached. These KPIs could comprise, for example: 


e functional coverage of the application components (e.g., percentage of functions 
that are supported by computer-based application components, or percentage of 
documents created in computer-based form), 

e standardization of the information system’s architecture (e.g., percentage of 
interfaces using standards such as Health Level 7 (HL7)), 

e homogeneity of the architecture (e.g., number of different application 
components), 

e availability of the application components (e.g., downtimes per year), 

e performance of the application components (e.g., response time), 

e user satisfaction (e.g., quantifiable by regular user surveys), 

e costs for management of information systems (e.g., overall costs, costs in relation 
to number of users or number of workstations), 

e quality of IT training (e.g., IT training hours per user), 

e quality of IT support (e.g., number of hotline calls that are successfully solved 
within 2 h), 

e quality of strategic management of information systems (e.g., percentage of suc- 
cessfully initiated IT projects as planned in the strategic project portfolio or the 
annual project portfolio), and 

e quality of tactical management of information systems (e.g., percentage of suc- 
cessfully completed IT projects). 


In Chap. 5, we will further discuss indicators for the quality of an information 
system and how they can be structured. 

These KPIs should be recorded in quantitative and, as far as possible, in auto- 
mated form to allow monitoring on a regular basis. Example 4.8.2 presents some 
KPIs of the information system of Ploetzberg Hospital. 
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Besides monitoring those indicators, data from other sources can also be related 
to the quality of the information system and thus be of interest for management of 
information systems as well, such as data from patient satisfaction surveys, medical 
error reports, or commentary on the health care facility in the local press. In addi- 
tion, national legislation (e.g., new data protection law) and standardization initia- 
tives (e.g., new version of HL7) should be monitored, as both may affect the 
information system. 

Sudden changes in monitored numbers can indicate problems (e.g., malfunction- 
ing of a component), which could then initiate more detailed analysis and correc- 
tions that are then to be initiated by strategic directing. 

Permanent monitoring activities can be used to identify areas of improvement, 
but they can also be used to compare the quality of the information system with 
other organizations or with established standards in the form of benchmarking. 
Some benchmarking approaches are presented in the following section. 


4.3.2.2 Benchmarking of Health Information Systems 


Benchmarking in general describes a process in which organizations evaluate vari- 
ous aspects of their performance and compare it to given standards or to the best 
organizations (“best practice”). Benchmarking uses quantitative criteria (KPIs) for 
comparing situations. 

In strategic management, benchmarking is seen as an important approach to 
assess the performance of a health care facility. Benchmarking is often seen as part 
of a continuous quality improvement process in which health care facilities measure 
and then steadily improve their performance. 

In strategic management of the information system of a health care facility, 
benchmarking can be used to assess the quality and costs of the information system 
in comparison with the information system of comparable facilities. Often, regional 
groups of health care facilities join together on an ad hoc basis to define and com- 
pare benchmarking criteria. 

The Digital Maturity Self-Assessment [2], for example, measures how well sec- 
ondary care providers in England use digital technology to achieve a health and care 
system that is paper-free at the point of care. The assessment measures digital matu- 
rity against the following three key themes: readiness, meaning the extent to which 
health care facilities are able to plan and deploy digital services (e.g., strategic 
alignment and financing of IT); capabilities, meaning the extent to which health 
care facilities are using digital technology to support the delivery of care (e.g., IT 
use to support functions such as order management or decision support); and infra- 
structure, meaning the extent to which health care facilities have the underlying 
infrastructure in place to support these capabilities. These three key themes are self- 
assessed using a set of questions. Results can be easily compared between health 
care facilities to highlight opportunities for improvement or support investment 
decisions. 
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4.3.2.3 Ad hoc Monitoring Activities by Evaluation Projects 


Ad hoc monitoring activities may be initiated after larger changes of a component 
(e.g., introduction of a new application component) have been performed or when 
sudden larger problems have been observed. Ad hoc activities help to analyze a 
certain situation in detail in order to better understand the reasons of an observed 
problem or the consequences of a larger change. These ad hoc activities are con- 
ducted in the form of evaluation studies that are planned and conducted as evalua- 
tion projects by tactical management of information systems [3]. 

For example, during and after the introduction of a computerized physician order 
entry system (CPOE), its quality and its effects on clinical care could be analyzed 
using a selection of the following evaluation questions: 


e How accurate and complete is the ordering data entered into the CPOE system? 

e Is the offered functionality sufficient to support all steps of the ordering process? 

e Is there any redundant functionality with other components? 

e Is the CPOE system being used as intended and as trained? 

e Does the efficiency and quality of the ordering process change? 

e Are physicians satisfied with the new component? 

e What did the purchase and introduction of the component cost? 

e What do support and training of the component cost? 

e Are there any unexpected negative effects on clinical care? 

e What are areas of improvement of the CPOE system, for example, regarding 
functionality, integration, or training? 


Typically, quantitative and qualitative methods can be combined to answer such 
evaluation questions. Monitoring, as part of strategic management of information 
systems, collects and reports the evaluation results to directly give feedback to stra- 
tegic planning of the information system. 

We will discuss planning and conducting evaluation projects in more detail in 
Sect. 5.4. 


4.3.3 Strategic Directing 


Strategic directing of information systems is a consequence of planning and moni- 
toring the functions and the architecture of the information systems and the organi- 
zation of management of information systems. 

Directing, as part of strategic management of information systems, means trans- 
forming the strategic information management plan into action, i.e., systematically 
updating the information system to make it conform to the strategic plan. The sys- 
tem’s manipulation is usually done by the initiation of projects. The projects deal 
with the construction or further development of components of the informa- 
tion system. 
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The projects to be initiated are taken from the strategic project portfolio as estab- 
lished in the strategic information management plan. The decision to initiate certain 
projects is part of strategic information planning. Strategic directing is then respon- 
sible for their prioritization, coordination, and initiation. Planning, directing, and 
monitoring these projects are the tasks of tactical management of information sys- 
tems. Operational management will then be responsible for the proper operation of 
the components. An example of strategic directing is the initiation of a project for 
the introduction of the CPOE system. 

In detail, the following main tasks of strategic directing can be identified: 


e initiation of projects from the strategic project portfolio, 
e assignment of a project manager, 
e provision of the needed resources for the project. 


4.4 Tactical Management of Information Systems 


Tactical management of information systems deals with specific components at the 
information system’s three layers. It aims to introduce, remove, change, or maintain 
those components. Activities of tactical management of information systems are 
usually performed within projects. Projects are unique undertakings that are charac- 
terized by objectives, by restrictions with regard to available time and resources, 
and by a specific project organization. Projects have to be initiated as part of an 
information strategy, which is formulated in the strategic project portfolio of the 
strategic information management plan. The result of all tactical information man- 
agement projects is an updated information system [4]. 
Examples of projects of tactical management of information systems are: 


e analysis of the structure and processes of order entry, 

e selection and introduction of a new CPOE system, 

e replacement of an application system for discharge summary writing in outpa- 
tient units, 

e assessment of user satisfaction with a new application system for an intensive 
care unit (ICU). 


Planning, as part of tactical management of information systems, means plan- 
ning projects and all the resources needed for them. Even though tactical informa- 
tion management projects are based on the strategic information management plan, 
they each need an individual project plan. This project plan describes the project’s 
scope and motivation, the problems to be solved, the goals to be achieved, the tasks 
to be performed, the activities to be undertaken to reach the goals, and the resources 
needed to complete the project. 

Directing, as part of tactical management, means the execution of such tactical 
information management projects based on their project plan. Therefore, directing 
includes typical tasks of project management such as execution of the planned 
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Systems analysis and assessment 


System specification 


System selection 


System introduction 
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System evaluation 


Project termination 


Fig. 4.7 Typical phases of tactical information management projects 


working packages, resource allocation and coordination, and reporting of the proj- 
ect’s results. 

Monitoring, as part of tactical management, means continually checking whether 
the initiated project is running as planned and whether it will produce the expected 
results. Monitoring results may influence project planning, as a project’s plan may 
be updated or changed according to the results of the project’s monitoring in a given 
situation. 

Typically, tactical information management projects comprise a planning phase 
(including project initiation and planning), an execution phase (which is about mon- 
itoring the project and one or more of the following activities: system analysis and 
assessment, system specification, system selection, system introduction, and system 
evaluation), and a completion phase (Fig. 4.7). 


4.5 Operational Management of Information Systems 


Operational management of information systems is responsible for operating the 
components of the information system. It ensures their smooth operation in accor- 
dance with the strategic information management plan of the health care setting. 
Planning, as part of operational management of information systems, means 
planning organizational structures, procedures, and resources (e.g., finances, staff, 
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rooms, or buildings) that are necessary to ensure the faultless operation of all com- 
ponents of the information system. For example, operational management of infor- 
mation systems may require the installation of a user service desk and a service 
support system that enables the quick transmission of users’ error notes to the 
responsible services. Such systems, but also respective staff resources, need to be 
planned and be made available for a longer period. Therefore, they should be allo- 
cated based on the strategic information management plan. Moreover, planning in 
this context concerns the allocation of personnel resources on a day-to-day basis 
(e.g., planning of shifts for staff responsible for user support or network 
management). 

To guarantee the continuous operation of the most important components of an 
information system, it is helpful to draw up a long-term plan for operational man- 
agement of information systems. Such a concept should clarify which components 
have to be supported, who is responsible for the operational support, and what the 
intensity of operational support should be. Table 4.1 presents components, respon- 
sibilities, tasks, and the intensity that should be defined as part of the operational 
management concept for the computer-based part of an information system. 

As an example, a concept for operational management in a health care facility 
could clarify: 


Table 4.1 Dimensions to be considered for operational management of information systems of 
the computer-based part of an information system 


Dimension Facets 


Components | Decentralized application systems (e.g., in departments) 


Central application systems (e.g., patient administration system) 


Workstations 
Decentralized servers 


Central servers 


Networks 
Backbone 
Responsibility | Local (in departments) 


Central (in departments for information processing) 


Vendors 


Task First-level support (incident taking, incident analysis, problem-solving if 
necessary, user training) 


Second-level support (training courses, regular operation, data protection) 


Third-level support (software development, problem-solving, contact with 
vendors) 


l Intensity Availability (e.g., 24 h/day, 7 days/week) 
Presence (e.g., locally, by pager, by hotline) 


Timeliness (e.g., answering time < 2 h) 
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e Central servers and networks are supported by the central information manage- 
ment department, which offers first- and second-level support 24 h a day. A ser- 
vice desk guarantees response time in less than 1 h. Third-level support is 
provided for certain application systems by the vendors of the respective applica- 
tion software products. 

e Clients (e.g., personal computers (PCs)) are supported by the local technical staff 
in each department. They offer first- and second-level support during the day. 
They are available by mobile phone. 


Directing, as part of operational management of information systems, is the sum 
of all management activities that are necessary to implement the plan and to ensure 
proper responses to operating problems of components of the information system. 
This comprises, for example, providing backup facilities, operating a service desk, 
maintaining servers, and keeping task forces available to repair network compo- 
nents, servers, PCs, or printers. Directing in this context deals with engaging the 
resources planned in such a way that faultless operation of the information system 
is ensured. 

Monitoring, as part of operational management of information systems, deals 
with monitoring the proper working and effectiveness of components of the infor- 
mation system. For example, a network monitoring system may continuously be 
used to monitor the availability and correct working of network components of the 
health care facility. 

Typically, three levels of operational support can be distinguished. First-level 
support is the first address for all user groups with any kind of incidents disrupting 
the desired operating flow. It may consist, for example, of a central 24-hour hotline 
(service desk) responsible for first trouble shooting and the management of user 
accounts, or it may consist of decentralized information managing staff. When solu- 
tions cannot be found for the reported incidents during first-level support, second- 
level support must take over. This is performed by specially trained informatics 
staff, often located in the central information management department, who are 
usually responsible for the operation of the specific application components. The 
third-level support, finally, addresses the most severe problems that cannot be solved 
by the second-level support. It can be performed, for example, by specialists from 
the software vendor. 

Operation and maintenance of components of the information system are part of 
its operational management. However, if problems occur (e.g., frequent user com- 
plaints about a medical documentation and management system (MDMS)), appro- 
priate projects may be executed by tactical management of information systems 
(e.g., introducing a better version of the documentation system). 

Built on top of strategic and tactical management of information systems, opera- 
tional management thus offers users comprehensive services. These services go 
beyond simply delivering hardware and software. Rather, they are designed to help 
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users use these components in a way that is helpful for their professional work. Such 
services are also known as IT services. Thus, the information management depart- 
ment of a health care facility is an IT service provider that delivers IT services to its 
customers, the users of the facility’s information system. The management activities 
that serve to provide quality IT services are grouped under the term Information 
Technology Service Management (ITSM). ITSM therefore has the task to design, 
provide, deliver, and improve such customer-centered services. The Information 
Technology Infrastructure Library (ITIL) [5] is the de facto standard framework for 
ITSM. ITIL was developed for the British government in order to define best prac- 
tices for all governmental data centers. 

For operational management of information systems, ITIL recommends setting 
up the following processes in particular: 

The incident management process deals with the handling of incidents that dis- 
rupt users in the completion of their work (e.g., a non-functioning application sys- 
tem or printer). The aforementioned service desk is used to receive complaints 
about such incidents. If a solution for the customer cannot be found there immedi- 
ately, the incident is declared a problem and passed on to the problem management 
process. If the problem management process reveals that changes need to be made 
to the components directly affected by the incident or to other components of the 
information system, the change management process will handle this. Since both 
small and large changes can always have side effects, ITIL also recommends a 
change management board as part of the process to coordinate and monitor the 
required changes. Incident, problem, and change management all require configura- 
tion management. With this term, ITIL means the processes that ensure that man- 
agement of information systems always has a correct overview of all components of 
the information system and their connections, i.e., the information system’s con- 
figuration. Corresponding configuration management systems can be based on 
3LGM? and the three levels defined there (Sect. 2.14). 

Especially in a health care facility, where human lives may depend on the proper 
operation of the information system, it is recommended to have a systematic ITSM 
and to follow ITIL. 


4.6 Organizational Structures for the Management of Health 
Information Systems 


Organizational structures for management of information systems differ greatly 
among health care facilities. In general, for each facility the adequate organization 
for strategic, tactical, and operational management of information systems and its 
proper integration into the decision structures of the facility must be established by 
IT governance as mentioned before. The resulting structures will depend on the 
facility’s size, internal organization, needs, and goals. 
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Organizational structures can be described at the level of the health care facility 
as a whole (e.g., a chief information officer, a central information management 
department) and at the departmental level (e.g., specific information management 
staff for a certain department, a certain outpatient unit). We will now look at the role 
of the CIO and the information management department in more detail. 

In this section, we first discuss IT governance and the decision-making processes 
before discussing important roles in this context: the CIO, the Information 
Management Board, and the Information Management Department. 


4.6.1 IT Governance and Organizational Structures 
for Information Management 


IT governance is the part of the overall management of a health care facility that 
deals with the organizational structures for decision-making in management of 
information systems [6]. The decision-making structures must be defined in such a 
way that the management of information systems is well integrated with the facili- 
ty’s management and is aligned to its strategic goals. 

The organizational structures for decision-making must enable the management 
of information systems to create value for stakeholders (compare Sect. 1.3 for a list 
of stakeholders and their requirements) and minimize risks related to the informa- 
tion systems. Simply said, IT governance focuses on which organizational struc- 
tures are needed to achieve value from the information system, and management of 
information systems describes how to use the structures for creating this value by 
properly planning, directing, and monitoring the information system. 

In order to find the right organizational structures for decision-making for a 
health care facility, one should first be clear about the fields in information manage- 
ment where decisions need to be made. In strategic information management, these 
are, in particular, decisions on the planned state of the facility’s information system 
as part of the creation of the strategic information management plan. This includes 
decisions on the application systems to be used (Sect. 3.4), the architectural style to 
be used (Sect. 3.6), the design of the IT infrastructure (Sect. 2.11), and the basic IT 
principles that should be followed. IT principles refer, for example, to the use of 
certain standards (Sect. 3.7.2). In addition, there are the decisions on the migration 
path and the associated strategic project portfolio (Sect. 4.3.1.2). Of particular 
importance are the financial decisions about the amount of investment in the infor- 
mation system and the allocation of the (limited) budget among the projects in the 
portfolio. In tactical information management, decisions must be made within the 
projects about the project plan and repeatedly about the appropriate execution of the 
individual project steps. In operational information management, decisions must be 
made repeatedly, especially about the prioritization of daily tasks. 
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Decisions in these decision-making fields can be made in different constellations 
depending on the circumstances of the health care facility and the management 
culture customary there. The types of such constellations described in the literature 
include business and IT monarchies as well as feudal and federal structures. In the 
monarchical constellations, the decision on the information system is made by the 
top management of the facility or by the information management leadership. 
Advisory bodies are often used to prepare the decisions. In feudal constellations, 
decisions are delegated to the management of sub-departments, such as the medical 
departments. In federal constellations, decisions on the information system tend to 
be made collegially by bodies such as an information management board (Sect. 
4.6.3). Federal constellations are particularly common in large institutions or even 
corporate groups, as they are most likely to take into account both local characteris- 
tics and the interests of various stakeholders. Anarchic situations can also be 
observed, in particular in large institutions, though they may be desirable, for exam- 
ple in academia as a way of promoting creativity. 

A framework for implementing IT governance principles in companies is COBIT 
(Control Objectives for Information and Related Technology) which is published by 
the Information Systems Audit and Control Association (ISACA). COBIT defines 
goals both for the governance and the management of information systems. 
Furthermore, it describes processes and best practices that must be implemented in 
a company in order to achieve value creation through the information system and 
information. COBIT is being continuously developed and is currently available in 
version COBIT 2019 [7]. 

Depending on the decision-making field (see above), the decision-making con- 
stellations in the same facility may well vary. Regardless of the decision-making 
constellations chosen, two structures are indispensable: the CIO and the informa- 
tion management department he or she is in charge of. 


4.6.2 Chief Information Officer (CTO) 


It is generally useful to centralize responsibilities for the management of informa- 
tion systems in one role. In larger health care facilities such as hospitals, this role is 
usually called chief information officer (CIO) . Other common designations include 
vice president (or director) of information systems, of information services, of man- 
agement of information systems, of ICT, or of information resources. 

The CIO bears overall responsibility for the strategic, tactical, and operational 
management of the information system and the budgetary responsibility and has 
authority over all employees concerned with management of the information sys- 
tem. The specific position of the CIO demands dedicated medical informatics com- 
petencies, executive and managerial competencies, and economic competencies. 
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Depending on the size of the health care facility, the role and the tasks of a CIO 
may be performed by one dedicated person (e.g., a full-time medical informatics 
specialist) or may be covered by another high-ranking role within the top manage- 
ment (e.g., by the chief executive officer (CEO)). 

Sometimes, the role of CIO is supported or replaced by more specific roles such 
as the chief medical information officer (CMIO) and the chief nursing information 
officer (CNIO), each responsible for the related clinical aspects of information 
management. 

If the institution has an information management board (Sect. 4.6.3), it is usually 
chaired by the CIO. Conversely, the leader of such a board is often considered the 
CIO if the position of CIO has not been explicitly established. 

Ideally, the CIO should report directly to the top management of the health care 
facility and, therefore, should be ranked rather high in the organizational hierarchy. 
For example, the CIO may be chair of the information management department and 
in this role directly report to the CEO. 

The CIO’s role should be a strategic one that comprises the following tasks of 
strategic management of the information system: 


e make or prepare all relevant strategic decisions on the information system, espe- 
cially with respect to infrastructure, architecture, and information management 
organization, 

e align the vision, mission, and strategy of the health care facility with the strategic 
information management plan, 

e establish, promote, and implement the strategic information management plan, 

e oversee tactical management of the information system and the project portfolio 
in order to prioritize and initiate its projects, 

e initiate evaluation studies and adequate monitoring activities of the informa- 
tion system, 

e oversee operational management of the information system and identify and 
solve serious information system problems, and 

e report to the CEO or the board of directors. 


The CIO’s close relation to or, in some cases, even the membership within the 
top management team should provide the possibility to influence the vision and mis- 
sion of the health care facility using IT as a strategic resource. Therefore, both busi- 
ness and medical knowledge and the ability to effectively communicate with other 
managers, for example, the chief financial officer (CFO) or the nursing director, is 
important for a CIO. 

In some cases, the CIO may focus more on tactical and even operational manage- 
ment of the information system than on its strategic management. This may depend 
on the size and internal organization of the health care facility, such as top manage- 
ment membership, internal communication networks among top executives and the 
CIO, top management’s strategic knowledge about the strategic role of the informa- 
tion system, and the personality of the CIO. 
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4.6.3 Information Management Board (IT 
Steering Committee) 


As explained in Sect. 4.6.1, in federal decision-making structures, strategic deci- 
sions on the information system tend to be made collegially by bodies such as an 
information management board. Members of this board are typically high-level rep- 
resentatives from the top management and from the main departments of a health 
care facility (see Sect. 4.8.3 for an example). Such a board is often referred to as the 
IT Steering Committee. 

If the institution has an information management board, it is usually chaired by 
the CIO. Conversely, the leader of such a board is often considered the CIO if the 
position of CIO has not been explicitly established. 

An information management board is particularly common in large institutions 
or even corporate groups, as they are most likely to take into account both local 
characteristics and the interests of various stakeholders. 


4.6.4 Information Management Department 


In larger health care facilities, there is usually one central information management 
department (often called the department for medical informatics, data center, or ICT 
department). This department handles the facility’s strategic management of the 
information system and at least of the tactical and operational information manage- 
ment of those parts of the information system with facility-wide relevance (e.g., the 
enterprise resource planning system (ERPS), the medical documentation and man- 
agement system (MDMS), and the computer network). 

In larger health care facilities, the information management department may 
consist of units that are responsible for certain tasks (e.g., different units for incident 
management, project management, clinical systems, administrative systems, IT net- 
works, or medical devices). If the information management department also handles 
the strategic management of the information system, the head of this department 
can be considered the CIO. 

With regard to the responsibilities for tactical and operational management of the 
information system, it is sometimes not useful and often not feasible to totally cen- 
tralize these services. Especially in larger health care facilities, the services are per- 
formed in cooperation between central units and the decentralized staff. This staff 
may be comprised of dedicated medical informaticians or especially skilled users. 
These local information managers have responsibilities for tactical and operational 
management of the information system with regard to their own department but in 
accordance with the central information management department. For example, 
they may (with support from the central unit) introduce a facility-wide application 
component in their department and operate it. On the other hand, they will also have 
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to handle additional information needs of their departments, for example, by intro- 
ducing a dedicated departmental system. However, this should be done only in 
accordance with the strategic information management plan. 

In Sect. 4.8.3, we present as an example the organizational structure of informa- 
tion management of Ploetzberg Hospital. 


4.7 Balance as a Challenge for the Management of Health 
Information Systems 


After reading the previous sections, it may seem that management of information 
systems must merely define strategic goals for management of information systems, 
aligned with the business goals of the health care facility, and work towards them. 
However, reality is not that simple. Management of information systems is a lot 
about balancing priorities between various and often conflicting goals. We will now 
discuss five aspects of this task of “balancing” priorities. 


4.7.1 Balance of Homogeneity and Heterogeneity 


The collection of information processing tools (both on the logical and at the physi- 
cal tool layer) should be as homogeneous (i.e., comparable in appearance and 
usability, for example, using tools from the same vendor) as possible and as hetero- 
geneous as necessary. In general, a homogeneous set of information processing 
tools makes training and support of users easier and thus leads to reduced costs for 
the health information system. However, in reality, we usually find a very heteroge- 
neous set of tools at both the logical and the physical tool layer. Why? 

In any health care facility, we need application systems at the logical tool layer 
for the support of the functions. Maximum homogeneity, at least for the computer- 
based part of a health information system, can easily be reached by a (DB', AC', V') 
architecture, when just one application system exists that is implemented through a 
single application software product from a single manufacturer. Usually, however, 
diverse application software products from different manufacturers have to be pur- 
chased, which can lead to very heterogeneous (DB", AC", V") architectures. These 
products might please the various stakeholders of the health care facility (which will 
all have optimal support for their tasks), but they will make integration, operation, 
and user support much more difficult. These difficulties are often overlooked by the 
stakeholders concerned. In this situation, it is the task of the management of infor- 
mation systems to ensure and support an appropriate compromise between the need 
for economical homogeneous information processing and the needs of the various 
stakeholders. 
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At the physical tool layer, heterogeneity is often the consequence of the evolu- 
tion of the health information system, comprising different generations of computer 
systems. This could be prevented only if all components are completely exchanged 
regularly, which is generally not sensible. In addition, heterogeneity is not always 
bad. For example, different mobile tools (laptops, tablets, and smartphones) may be 
needed to best support different user needs in different situations. But again, when 
this heterogeneity of information processing tools is not systematically managed, it 
can lead to the uncontrolled proliferation of tools and to unnecessary costs. 

The better all stakeholders are involved in strategic management of information 
systems through an appropriate organization, the more this situation can be avoided. 


4.7.2 Balance of Computer-Based and Paper-Based Tools 


It is the task of managing health information systems to manage information pro- 
cessing in such a way that the strategic goals of the health care facility can best be 
reached. For a health care facility whose goal it is to provide very personal and 
humane treatment, it might therefore make sense to abstain from the use of technol- 
ogy and especially computers for all immediate physician—patient contact. This 
would include, for example, writing with paper and pen (or with the so-called digi- 
tal pens) during a direct physician—patient encounter, rather than using a computer 
for data entry, as this may help support this strategic goal. 

For a health care facility whose goal involves technological leadership and inte- 
grated processes, it might be more appropriate to proceed in the opposite direction, 
i.e., to strive for a good support of all working processes through computer- 
based tools. 

That is, the optimum of computer support is not defined by the maximum; rather, 
it evolves through the strategic goals of the health care facility and its stakeholders 
as well as through the functions to be supported. 


4.7.3 Balance of Data Security and Working Processes 


The data stored in a health information system are worth protecting. Patients must 
be confident that their data will not be made available to an unauthorized third party. 
To ensure this, the appropriate laws of the particular country are to be adhered to. 
However, health information systems are not just purely technical, but rather are 
socio-technical systems. This means that people are also part of the information 
system and are therefore also responsible for data security and protection. 
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A health information system should implement strict access control methods to 
ensure that unauthorized access is impossible. However, this can lead to hindrances 
in the daily work of the health care professionals. For example, it may occur that a 
medication cannot be prescribed in an emergency when the attending physician 
belongs to another hospital department and therefore does not have the right to read 
the lab result or to order a medication. This can, in an extreme case, even lead to a 
life-threatening situation. Thus, an access control system that is strict and adapted 
to predefined tasks and roles in a department can hinder the cooperation between 
health care professionals and other departments. This would be unfortunate, as it is 
the job of the management of information systems to build the health information 
system in such a way that cooperation is supported. Consequently, following a thor- 
ough risk analysis, it should be weighed whether access control measures in certain 
situations should be less strict for medical staff, thereby strengthening their own 
level of responsibility. 

Similar risks should be considered in determining how long data should be kept. 
Health care laws, research needs, and lawsuit requirements should be addressed. So, 
for example, following the expiration of the storage period, if documents are 
destroyed, it could be difficult to prove that the hospital carried out a correct medi- 
cal process in the event of a lawsuit. The resulting consequences would be requests 
for damage compensation and possibly punishment. However, long-term storage of 
data may be costly and space-consuming (e.g., archive room, disk storage capacity). 
Risk management must be carried out with strong support from the health care facil- 
ity’s management. 


4.7.4 Balance of Functional Leanness 
and Functional Redundancy 


Functional leanness describes a situation where one function is supported by one 
and only one application component. The opposite is functional redundancy where 
a specific function is supported by more than one application components. For 
example, imagine a health care facility where two different NMDS are in use, one in 
the surgical units, and the other in the other units. In this case, central functions such 
as nursing care planning are supported by two application systems. This situation 
will result in additional costs both for investment, maintenance, training, and sup- 
port. But as discussed with controlled data redundancy, functional redundancy is not 
always bad and may best support the specific needs of the users in the different areas. 

Functional redundancy may also be found between different types of application 
systems. For example, patient admission may be supported by application systems 
other than the patient administration system to allow easy patient admission during 
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nighttime, for example, in a radiology department, by using the radiology informa- 
tion system (RIS). This situation may be suitable, as it will provide a more conve- 
nient and well-known tool in the diagnostic area and a faster and more sophisticated 
tool in the patient administration unit. However, clear organizational rules and inter- 
faces between both application systems are needed to achieve data integration and 
to avoid double documentation or transcription. 

Thus, it is the management’s task to check carefully where and why there is 
functional redundancy because unmanaged functional redundancy may lead to dis- 
ruptions of work processes, confusion of users, and unnecessary costs. If needed, 
application systems or functions within application systems need to be removed to 
increase functional leanness. 


4.7.5 Balance of Documentation Quality 
and Documentation Efforts 


Documentation of clinical data is needed for many purposes, such as for informa- 
tion exchange within the health care team, for clinical decision-making, for clinical 
research, for reimbursement issues, for hospital controlling, and for legal statistics. 
Consequently, many groups inside and outside the hospital profit from a complete, 
accurate, and timely clinical documentation. 

On the other hand, high-quality documentation takes time. Physicians and nurses 
may feel that the time needed for documentation reduces the time they have for 
patient care. The feeling is especially strong in facilities where documentation is 
not well supported by existing tools and documentation processes. Insufficient orga- 
nization of documentation may lead to documentation that is more time-consuming 
than necessary, to double documentation of the same data, and to transcriptions and 
media breaks. This all reduces the motivation for documentation and may lead to 
the feeling that documentation is not helpful but a burden. This in turn may reduce 
the quality of the documented data. This fact is especially relevant if data items need 
to be documented by staff that will not use this data for their own purposes. Due to 
the integrated nature of the processes within a hospital, this is rather common. 

Management of information systems must therefore carefully balance the amount 
of documentation that is really needed for the various purposes and the effort that 
health care professionals have to invest. Well-designed documentation forms, high 
level of standardization, integrated documentation tools, and a systematic planning 
of documentation help to reduce effort and to increase the awareness that documen- 
tation is an important and indeed useful part of clinical practice. 
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4.8 Examples 


4.8.1 Strategic Information Management Plan 


of Ploetzberg Hospital 


Table 4.2 presents the structure of the strategic information management plan of 
Ploetzberg Hospital. 


Table 4.2 Structure of the strategic information management plan (2022-2026) of Ploetzberg 
Hospital 


Management Summary 


1. 


Intention of this strategic information management plan 


2. 


Ploetzberg Hospital and Medical School 
2.1 Hospital mission statement 

2.2 Strategic hospital goals 

2.3 Environment analysis 

2.4 Organizational structure 

2.5 Hospital indicators 

2.6 Hospital layout 


. Current state of the information system 


3.1 Goals of management of the information system 

3.2 Organization of management of the information system 

3.3 Guidelines and standards for the management of the information system 
3.4 Functionality 

3.5 Application components 

3.6 Physical data processing systems 


. Assessment of the current state of the information system 


4.1 Goals attained 
4.2 Weak points and strengths of the information systems 
4.3 Required activities 


. Future state of the information system 


5.1 Visions and perspectives 

5.2 Planned functionality 

5.3 Planned application components 

5.4 Planned physical data processing systems 

5.5 Planned organization of the information management 


. Planned activities until 2028 


6.1 Project portfolio 
6.2 Time planning 
6.3 Cost planning 


. Conclusion 
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4.8.2 Health Information System Key Performance Indicators 
(KPIs) of Ploetzberg Hospital 


The CIO of Ploetzberg Hospital annually reports to the hospital’s management 
about the amount, quality, and costs of information processing of the Ploetzberg 
Hospital information system. For this report, the CIO uses health information sys- 
tem KPIs that have been agreed on by a regional group of hospital CIOs (Table 4.3). 
Each year, the hospitals exchange and discuss their reports as part of a best practice 
benchmark with other hospitals—this comparison is not shown in the table. 


Table 4.3 Extract from the Ploetzberg Hospital health information system’s benchmarking report 
2024. KPI key performance indicator 


KPIs for the hospital 

Number of staff 5500 
Number of beds 1100 
Number of inpatient cases 40,000 
Mean duration of stay 8.1 days 
Hospital budget €800 million 
KPIs for health information system’s costs 

Overall IT costs €20 million 
IT costs per inpatient case €500 

IT costs in relation to hospital budget 2.5% 
KPIs for health information system’s management 

Number of HIS staff 46 
Number of HIS users 4800 
Number of workstations 1350 
Number of mobile IT tools 2500 
HIS user per mobile IT tool 1.9 
Number of IT problem tickets 15,500 
Percentage of solved IT problem tickets 96% 
Availability of the overall HIS systems 98.5% 
Number of finalized strategic IT projects 13 
Percentage of successful IT projects 716% 
KPIs for health information system’s functionality 

Percentage of all documents available electronically 45% 
Percentage of all diagnosis coded electronically 711% 
Functionality index of patient administration system 52% 
Functionality index of MDMS 87% 
KPIs for health information system’s architecture 

Number of computer-based application components 84 
Percentage of standard interfaces between applications 87% 
Functional redundancy rate 0.44 
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4.8.3 Organization of the Management of the Ploetzberg 
Hospital Information System 


Figure 4.8 presents the organization of management of the information system of 
Ploetzberg Hospital. The CIO here is Mrs. Garzia. She is head of the information 
management department and also chair of the information management board. In 
both positions, she is responsible for strategic, tactical, and operational manage- 
ment of the information system at the hospital. The operational management of the 
information system is partly supported by local information managers (e.g., techni- 
cal specialists or medical informaticians) in dedicated department such as the radi- 
ology or the cardiology. 

Mrs. Garzia directly reports to Mrs. Johns, the CEO of Ploetzberg Hospital. 
Recently, both discussed the strategic information management plan that is just 
being updated. The discussions focused on the question whether the strategic 


Top management Grisi acco Gisa Mrs. Johns 
— 
Managing director Mrs. Koch 
Role/Position 
Medical director Mr. Thomas 
Individuals 
Director of nursing Mr. Weber 
~— Superior or subordinate (directs) 
— Assignment (belongs to/perceives) Information Head of the information 
management board management department Mrs. Garzia 
(Clo) 
Representative from the top| Mr. Weber 
management 
Representative from the 
main departments | (Mes SVE 
Mr. Hess 
Information Head of the information 
management management department Mrs. Garzia 
department (CIO) 
— 
Information management Mr. Nielsen 


staff 


Mr. Hernandez 


Mrs. Smith 
Radiology Head of the department Cardiology Head of the department of 
(Department 1) of radiology Mpina (Department 2) cardiology Me Smyrek 
Local information manager Local information manager 
radiology cardiology 
Mr. Müller Mr. Holsten 
Mrs. Perterson 


Fig. 4.8 Extract from the organizational structure of the management of the information system at 
Ploetzberg Hospital 
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information management plan is fully aligned with the general business goals of 
Ploetzberg Hospital. As CEO, Mrs. Johns will present and approve the strategic 
information management plan in the next meeting of the top management. 

The draft of the strategic information management plan was developed by Mrs. 
Garzia. It already has been discussed and confirmed by the information manage- 
ment board. This board includes a representative from top management (e.g., the 
director or nursing) as well as the deputy head physicians of the radiology depart- 
ment, Mr. Hess, and of the cardiology department, Mrs. Smyrek. The board sup- 
ported Mrs. Garzia in aligning the strategic information management plan with the 
needs and requirements of the clinical departments. 


4.9 Exercises 


4.9.1 Activities of Managing Information Systems 


In Sect. 4.2, we introduced a three-dimensional classification of activities of man- 
agement of information systems (Fig. 4.2). How would you describe the scope and 
tasks of the following activities of managing information systems? 


e Developing a strategic information management plan (e.g., this is related to stra- 
tegic planning), 

e Initiating projects from the strategic project portfolio, 

e Collection and analysis of data from user surveys on their general satisfaction 
with the health information system, 

e Planning a project to select and introduce a new CPOE system, 

e Executing work packages within an evaluation project of a CPOE system, 

e Assessment of user satisfaction with a new intensive care system, 

e Planning of a user service desk for a group of clinical application components, 

e Operation of a service desk for a group of clinical application components, 

e Daily monitoring of network availability and network failures. 


4.9.2 Strategic Alignment of Hospital Goals and Information 
Management Goals 


Imagine you are the CIO of a hospital in which almost no computer-based tools are 
used. One of the hospital’s goals is to support health care professionals in their daily 
tasks by offering up-to-date patient information at their workplace. 

Which main goals for management of information systems could you define 
based on this information? Which functions should be prioritized to be supported by 
new application systems? What could a strategic project portfolio and a migration 
plan for the next 5 years look like? 
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4.9.3 Structure of a Strategic Information Management Plan 


In Sect. 4.8.1, we presented the structure of the strategic information management 
plan of Ploetzberg Hospital. Compare its structure to the general structure presented 
in Sect. 4.3.1.2, consisting of strategic goals, description of current state, assess- 
ment of current state, future state, and migration path. Where can you find this 
general structure in Ploetzberg Hospital’s plan? 


4.9.4 An Information-Processing Monitoring Report 


Look at the health information system’s KPIs of Ploetzberg Hospital in Example 
4.8.2. Try to figure out some of these numbers for a real hospital and compare both 
hospitals’ KPIs in the form of a benchmarking report. It may help to look at the 
strategic information management plan of this hospital or at its website. 


4.9.5 Relevant Key Performance Indicators (KPIs) 


Imagine you are the CIO and have to select the three most relevant indicators for the 
quality of your information system at your hospital: Which would you select? You 
can look at the examples in Sect. 4.8.2 to get ideas. Explain your choice. 


4.9.6 Organizing User Feedback 


You are asked to organize regular (e.g., every half year) quantitative user feedback 
on the general user satisfaction with major clinical application components of your 
hospital as part of health information system’s monitoring. Which user groups 
would you consider? How could you gather user feedback regularly in an automatic 
way? Explain your choice. 


4.9.7 Information Systems Managers as Architects 


Information systems managers can be partly compared to architects. Read the fol- 
lowing statement and discuss similarities and differences between information sys- 
tem architects and building architects [8]: 

“We are architects. [...] We have designed numerous buildings, used by many 
people. [...] We know what users want. We know their complaints: buildings that 
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get in the way of the things they want to do. [...] We also know the users’ joy of 
relaxing, working, learning, buying, manufacturing, and worshipping in buildings 
which were designed with love and care as well as function in mind. [...] We are 
committed to the belief that buildings can help people to do their jobs or may impede 
them and that good buildings bring joy as well as efficiency.” 
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Chapter 5 A 
Quality of Health Information Systems igg 


5.1 Introduction 


The International Organization for Standardization (ISO) defines quality in general 
as the ability to meet all the expectations of the purchaser of goods or services or, in 
other words, as the degree to which a set of inherent characteristics fulfills require- 
ments, where “requirements” means needs or expectations. 

In Sect. 1.3, we already discussed the requirements of various stakeholder groups 
and their expectations on the information system. In this chapter, we will now dis- 
cuss in more detail the various aspects of the quality of a health information system. 
Assessing the quality of health information systems using quality characteristics, 
and maintaining this quality, is one of the tasks of managing information systems 
(Fig. 5.1). 

After reading this chapter, you should be able to 


e describe different quality characteristics of the management of the information 
system in a health care facility, 

e describe different quality characteristics of the information system of a health 
care facility, and 

e describe the steps of systematically evaluating quality characteristics of the man- 
agement of the information system or of the information system itself. 
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Fig. 5.1 Health information systems constitute an essential part of providing good health care. 
Consultant physician reviews data on a ward 


5.2 Quality of Management of Information Systems 


In Chap. 4, we discussed the tasks of strategic, tactical, and operational manage- 
ment of information systems and the related organizational structures of informa- 
tion management. We also introduced IT governance and Information Technology 
Service Management (ITSM). We will now use a top-down structure when discuss- 
ing the quality of management of information systems, starting with the quality of 
IT governance and finishing with the quality of ITSM. 


5.2.1 Quality of IT Governance 


IT governance is part of the overall management of a health care facility. It aims at 
providing appropriate organizational structures for managing the information sys- 
tem in such a way that it creates value for stakeholders. 

To assess the quality of IT governance, we can assess the following aspects: 

IT governance structures should be established that enable the management of 
information systems to create value for stakeholders and minimize risks related to 
the information systems (Sect. 4.6.1). For example, responsibilities for strategic, 
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tactical, and operational management need to be clearly assigned to organizational 
units (such as the Information Management Department, Sect. 4.6.3) or roles (such 
as the chief information officer (CIO), Sect. 4.6.2). IT governance should be based 
on established best practice frameworks and standards, such as COBIT (Control 
Objectives for Information and Related Technology). COBIT is an international 
framework for IT governance that defines a set of generic processes for the manage- 
ment of IT in an organization for each of these processes. COBIT defines objectives, 
key activities, inputs and outputs, and performance measures. Processes defined by 
COBIT [1] include managing the strategic information management plan, manag- 
ing project portfolios, IT risk management, IT change management, ITSM, or IT 
Operation. 

In addition, enough resources should be provided for IT staff, IT infrastructures, 
and application components so that the information system can best meet the busi- 
ness demands. For example, the annual IT budget should be sufficiently high to hire 
qualified staff to manage the information system. 

Finally, the health information system should be operated in such a way that all 
information management laws of the specific country are fulfilled. Different laws 
must be fulfilled in every country, such as laws regarding data protection, data inter- 
change, IT security, or health statistics. These laws must be taken into account by 
management of information systems. 


5.2.2 Quality of Strategic Management of Information Systems 


Strategic management of the information system deals with the information pro- 
cessing of a health care facility as a whole. It depends on the facility’s business 
goals and must translate these into an appropriate strategic information manage- 
ment plan. 

To assess the quality of strategic management of information systems, we can 
look at the following aspects: 

First, a strategic information management plan should exist and should be 
updated regularly. It should be closely and visibly aligned with the business strategy 
and business goals of a health care facility. This means that the outcome of manag- 
ing information systems, i.e., the information system itself, should clearly support 
the business goals of the health care facility. For example, the resulting health infor- 
mation system should support business goals such as high-quality care of chroni- 
cally ill patients, participation in cross-institutional clinical research, or attracting 
patients from neighboring regions. 

In other words, information logistics should be possible in a way that it supports 
all intended business processes and functions and fulfills the need of the various 
stakeholder groups (physicians, nurses, management, patients and their relatives, 
researchers, etc.). We already discussed the requirements of the various stakehold- 
ers in Sect. 1.3. If management of information systems is to be considered success- 
ful, then the information system should fulfill the requirements of these stakeholder 


192 5 Quality of Health Information Systems 


groups. The strategic information management plan should thus be developed with 
input from major stakeholder groups within the health care facility. Details on how 
to develop a strategic information management plan were explained in Sect. 4.3.1.2. 

This also means the IT project portfolio (Sect. 4.3.1) should be effectively man- 
aged in a way that maximizes the intended value to the health care facility and to the 
stakeholders. For example, projects that deliver the most business value (e.g., the 
introduction of a picture archiving and communication system (PACS) to support 
faster and better diagnosis and treatment) may be prioritized among other projects 
(e.g., a website for clinical staff informing on most recent business news) depending 
on the business goals. 

Strategic monitoring should be done based on clearly defined key performance 
indicators (KPIs) and use data from several sources (e.g., user surveys, analysis of 
hotline calls). Evaluation projects should be conducted to assess the quality of cer- 
tain parts of the information system. For example, after the introduction of a new 
computerized provider order entry (CPOE) system, changes in medication errors 
should be analyzed systematically. Details on how to plan and conduct evaluation 
projects are discussed in Sect. 5.4. 

IT risk management should continuously assess risks and liabilities of informa- 
tion management. This includes the continuous identification, assessment, mitiga- 
tion, monitoring, and management of risks related to IT. For example, an IT risk 
analysis may show that the whole hospital operation depends on the functioning of 
the communication server and of the IT network, and thus activities will be started 
to reduce the risk of network failures by increasing redundancy of technical 
components. 

Finally, the architecture of the information system should be documented in an 
up-to-date way. It is surprising how many health care facilities do not have a consis- 
tent and clear description of their application components, the functions they sup- 
port, and the interfaces between them. Establishing and using such an architectural 
description is an important activity within strategic information management plan- 
ning. Using the three-layer graph-based metamodel (3LGM7’) been described in 
Sect. 2.14 is helpful. 


5.2.3 Quality of Tactical Management of Information Systems 


Tactical management of information systems deals with particular functions, appli- 
cation components, or physical data processing systems. It aims to introduce, 
remove, change, or maintain components of the information system. 

There are some ways to assess the quality of tactical management of information 
systems: 

Projects of tactical management of information systems should be derived from 
the annual project portfolio. They should be conducted using best practices and 
state-of-the-art methods in project management in all project phases: project initia- 
tion, project planning, project execution, and project completion (Sect. 4.4). 
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All projects should be finalized within the planned time frame and within the 
planned budget. Changes in time frame and budget must be justified and approved 
by strategic management of information systems. Finally, and most importantly, 
projects should be successful, i.e., they should reach the intended project goals. 

As part of tactical management of information systems, certification may also 
play a role. Certification in general means confirming that an object or organization 
has certain characteristics. Certification of health information systems in general 
describes a process where an accredited body confirms that the information system 
of a health care facility fulfills certain quality characteristics that have been pre- 
defined by an external organization. Examples of certification are provided in 
Example 5.5.3. Vendors may try to obtain these certificates for their application 
software products to obtain an advantage in the market. Health care facilities may 
check for the availability of these certificates when buying software for a new appli- 
cation component. In general, certification increases transparency of different prod- 
ucts and fosters buyers’ knowledge about products, as certification organizations 
often compile information about the different products and technologies. Increased 
transparency and knowledge in turn have a positive impact on the buyers’ willing- 
ness to invest in new technology. Even when a certification does not guarantee that 
a component is good regarding all and every criterion, certification may contribute 
to an increased transparency of quality of health information systems in general. 


5.2.4 Quality of Operational Management 
of Information Systems 


Operational management of information systems is responsible for operating the 
components of the information system. It ensures its smooth operation in accor- 
dance with the strategic information management plan of the health care facility. 

To assess the quality of operational management of information systems, we can 
assess several aspects. 

First, we can assess whether the operation of the components of the information 
system (such as server, clients, networks, interfaces) runs smoothly and without 
frequent or longer interruption. 

To minimize risks, a business continuity plan should be available that describes 
how the information system can continue to support the functions even in a case of 
larger failures or disasters (e.g., when the central server room of a health care facil- 
ity is destroyed). 

As part of IT governance, there should be a clear responsibility with documented 
tasks and processes for operating the physical data processing systems and the 
application systems in a health care facility. 

Operational management of information systems should be based on established 
best practice frameworks and standards such as COBIT [1] as a framework for IT 
governance (Sect. 5.2.1) or Information Technology Infrastructure Library (ITIL) 
[2] for ITSM (Sect. 4.5). 
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ITSM provides a perspective on management of information systems that focuses 
on how IT is provided to serve the needs of customers. We can consider the manage- 
ment of IT services as that part of operational management of information systems 
focusing on responding to the customer’s needs. The term “IT service” in a health 
facility comprises the application systems (e.g., LIS or PACS) and the physical data 
processing tools (e.g., ward computers, mobile computers) discussed in Sects. 3.4 
and 3.10. However, it also comprises more specific IT services such as remote VPN 
(virtual private network) access to the network of the health care facility, specific 
application interfaces, antivirus shielding, or videoconferencing facilities. All these 
are IT services that are needed by customers (e.g., by the clinical departments or the 
administration of a health care facility). 

The desired content and quality of IT services should be clearly defined in service- 
level agreements (SLAs). An SLA describes, among other things, the processes sup- 
ported by the IT service (e.g., access to images via a PACS), the desired outcome for 
the customer (e.g., mobile access to all patient images is possible for a physician), 
planned service times (e.g., 24/7), availability target (e.g., 99% availability of image 
access), allowed downtimes (only during night), number of users (e.g., 350 physi- 
cians), required levels of support (e.g., on-site support during day, remote support 
during night), and responsibilities (including duties of the service provider, duties of 
the customer, duties of the service user). An SLA is a contract regarding the provi- 
sion of an IT service, for example, between a department and the IT department. 

An IT service desk, also called helpdesk, should be available where users can 
report any incidents related to IT services and get help. The quality of the IT ser- 
vices should be continuously monitored and improved. All incidents related to IT 
services should be systematically documented, their root causes should be analyzed, 
and ways to prevent future problems should be developed and implemented. 

Finally, IT staff should be sufficiently trained and competent to operate physical 
data processing systems and the computer-based applications. 


5.3 Quality of Architectures and Infrastructures 


In the previous section, we discussed the quality of the management of information 
systems. The outcome of high-quality information management is, hopefully, a 
high-quality information system. We will now discuss how we can assess the quality 
of the information system. 


5.3.1 Quality at the Domain Layer 


The overarching objective of a health information system is to support the functions 
of a health care facility. In Sect. 3.3, we presented these functions in more detail, 
such as patient identification, decision-making and patient information, execution 
of diagnostic, therapeutic, and nursing procedures, or billing. 
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Health information systems should sufficiently support information and knowl- 


edge logistics (Sect. 2.7) within patient care, administration, and management. To 
achieve a high quality of the information and knowledge logistics at the domain 
layer, information logistics should be as good as possible given the resources used. 
Good information and knowledge logistics comprises the following aspects: 


The right information: Is the information that the users need available? For 
example, can the physician access the lab results of a patient? 

At the right time: Is the information available when it is needed (just-in-time)? 
For example, are the most recent lab results available before the physician’s 
round starts? 

At the right place: Is the information available where it is needed? For example, 
are the recent lab results available at the patient’s bedside? Is information also 
available across health care facilities to support continuity of care (e.g., can hos- 
pital, nursing home, and general practitioner (GP) access relevant information on 
a given patient treated by all three facilities?) 

To the right people: Is the information available only to those who need it and 
who have the right to see the information? For example, are the recent lab results 
only available to the treating health care professionals? Is data protection guar- 
anteed? Is relevant information available not only for health professionals, but 
also for the patient and relatives? 

In the right form: Is the information available in a usable format? For example, 
can lab results also be displayed in a graphical way for a longer period of time? 
Can information be personally filtered (personal filtering), not overwhelming the 
health care professional with too much information (information overload)? 

In order to make the right decisions: Information should be used to inform deci- 
sions. For example, a graphical presentation of the lab results may show an 
increase in a lab value, which may in turn motivate the physician to change the 
administrated drug. 


In addition, the domain layer describes the data to be processed and provided. To 


assess the quality of the data at the domain layer, we can assess the following data 
quality aspects: 


Data integrity should be maintained. Data integrity means that data are consis- 
tent, that object identity is maintained, and that relationships between entities 
are correct (referential integrity) (Sect. 3.5). For example, every patient and 
every patient case should have a unique PIN that is used in all application 
components. 

Data in general should also be correct and have an indisputable authorship. For 
example, the author of every patient report should be clear and verifiable. Clinical 
data should also be kept confidential. For example, the diagnoses of a patient 
should only be accessible to the treating health care professionals. 

Finally, data should be uniformly recorded. There should be clear rules on which 
data and how the data are recorded and stored. Standardized data can be better 
processed automatically, while non-standardized data can provide more specific 
information to a human reader (Sect. 3.2.2). 
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5.3.2 Quality at the Logical Tool Layer 


The information system quality at the logical tool layer comprises the quality of 
application components and the quality of their integration. 
The following criteria help to assess the quality of an application component: 


e Application systems should offer the features required for a given process. For 
example, a radiology information system (RIS) should offer features required for 
report writing, it should provide correct output when searching for a patient, and 
it should guarantee security of stored data. 

e As clinical workflows often change, an application component should be adapt- 
able to workflow changes. 

e An application system should be reliable and provide defined services for a 
defined time under the given conditions. For example, an RIS should have little 
or no downtimes. An application system should also be easy to maintain. For 
example, an upgrade of the RIS software must be done quickly and without 
endangering the overall application component’s stability. 

e An application system should be user-friendly. Good usability is very important 
for software used within health care facilities. Health care professionals spend 
only a small amount of their working time with computer-based tools, and they 
often have to use various application components for their work. In addition, 
staff turnover is very high. Therefore, application software products should be 
easy to learn and intuitive to use. This is addressed by ISO 9241-171, which 
defines specific quality characteristics for software ergonomics, such as self- 
descriptiveness or tolerance with regard to user errors. 

e An application system may need to be certified depending on the legal regula- 
tions. For example, the PACS software is certified according to the national law 
for medical devices. 

e Finally, an application system should offer standardized interoperability inter- 
faces to facilitate integration with other application components (Sect. 3.7.2). 
For example, an R/S may offer a Health Level 7-based (HL7-based) interface for 
data exchange with the patient administration system or with other clinical sys- 
tems. Otherwise, integration in AC" architectures is hardly reachable in an eco- 
nomically reasonable way, as proprietary interfaces between two application 
components are expensive to develop and to maintain. 


The general architecture of the health information system should be sufficiently 
flexible to adapt to the changing needs of the hospital. For example, it should be 
easy to add new application systems to the information system, and application 
components should be easily replaceable by other (more advanced) application 
components. A star-based architecture (CP! architecture) with a communication 
server (Sect. 3.9.2) and application components offering standardized interfaces 
support the exchange or addition of application systems. 

An architecture can be called “saturated” if as many functions as possible are 
supported by computer-based tools and if there are no or only a small number of 
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non-computer-based tools still in use. Please note that computer-support is not a 
goal in itself. However, a mix of paper-based and computer-based tools within a 
function often leads to deficiencies in information logistics such as transcriptions. 
Transcription means the manual transfer of data from one application component to 
another, for example, manually entering patient diagnoses from the patient admin- 
istration system in the CPOE system or scanning a discharge letter to add it to the 
electronic patient record (EPR). Transcriptions are time-consuming and may lead to 
data errors. Therefore, transcriptions have to be avoided by using standardized inter- 
faces between application components. 

To achieve integration in “best-of-breed” architectures (AC", V”), application 
components need to share and store the same data. Data redundancy is thus unavoid- 
able. For example, patient administrative data are stored in the patient administra- 
tion system, the RIS, and the LIS. This data redundancy needs to be closely managed 
to provide consistent data. Approaches for handling data redundancy through inte- 
gration technologies were presented in Sect. 3.9. 


5.3.3 Quality at the Physical Tool Layer 


The information system quality at the physical tool layer comprises the quality of 
physical data processing systems and their integration. 

The quality of physical data processing systems can be described by several 
characteristics: 


e Physical data processing systems should be available where needed (e.g., at the 
patient bedside). They should be stable and reliable, i.e., without unexpected 
downtimes. They should be performant to allow fast processing and the ability to 
present large amount of data (including images). 

e Physical data processing systems should be secure, for example, following rules 
for data safety, data security, and electrical safety. They should be user-friendly 
(e.g., allowing data entry via touchscreen, mouse, and keyboard). In certain 
areas, they need be certified. For example, the tools used in the intensive care unit 
(ICU) need to be certified according to the national law for medical devices. 

e Physical data processing systems should be usable for several tasks. For exam- 
ple, a mobile tool (such as a notebook) on a ward should allow access to the 
nursing documentation system, the CPOE system, and the patient chart. This 
limits the risk that users have to handle multiple physical tools at the same time 
and thus supports the “leanness” of information-processing tools. 


At the physical tool layer, redundancy is often valuable to reduce risks of system 
failure. For example, data may be stored redundantly in different areas in order to 
avoid data loss in case of fire. Or data may be duplicated on different hard discs in 
a specific database server (e.g., using redundant array of independent discs (RAID) 
technology), allowing reconstruction of data when a hard disc fails. Thus, technical 
redundancy is also an important quality criterion for the physical tool layer. 
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5.3.4 Quality of Integration 


In Chap. 2, we learned that health information systems are constructs built from a 
variety of components. In Sect. 3.7, we discussed that these components, especially 
application systems, need to be interoperable so they can be integrated to best sup- 
port functions and business processes. Integrating application systems, as we saw in 
Sect. 3.8, can be done in a number of ways, each achieving specific qualities of the 
information system. We will therefore summarize these types of integration here 
again as quality criteria for health information systems. 

Data integration is achieved in a health information system when data that have 
been recorded in different application components once are available wherever they 
are needed without having to be reentered (Sect. 3.8.1). Consequently, in a health 
information system where data integration is given, data can be brought together for 
analysis wherever it is needed. Moreover, if the data needs to be updated, this only 
has to be done in one place, even if the data are redundantly stored in several appli- 
cation systems. Overall, data integration is the first and quite basic quality charac- 
teristic within heterogeneous health information systems, as it allows application 
systems to exchange and reuse data while preserving data integrity. 

Semantic integration (Sect. 3.8.2) is guaranteed if different application systems 
use the same system of concepts, i.e., they interpret data the same way. Semantic 
integration is an important quality characteristic within heterogeneous health infor- 
mation systems, as it supports the exchange of meaningful information between 
application systems. 

User interface integration (Sect. 3.8.2) is guaranteed when different application 
components represent data and organize their user interfaces in a unified way. User 
interface integration supports the usability of application systems and reduces errors 
when searching for or entering data. It thus also contributes to data quality and 
patient safety, making it an important quality characteristic within heterogeneous 
health information systems, as it supports ease-of-use and reduces usage errors of 
graphical user interfaces. 

Context integration (Sect. 3.8.4) is an important quality characteristic within het- 
erogeneous health information systems, as it allows synchronizing and coordinating 
context among application systems. It thus allows application systems to automati- 
cally follow patient, user, and other contexts and thus supports the user when work- 
ing with several application systems. Note that context integration stands on its 
own. It neither contributes to data, to semantic, or to user interface integration. Vice 
versa, these types of integration will not support achieving context integration. 

Feature integration (Sect. 3.8.5) means that features are not implemented redun- 
dantly in multiple application systems. Feature integration thus reduces costs for 
both implementation and maintenance of application systems. Overall, feature inte- 
gration is an important quality characteristic within heterogeneous health informa- 
tion systems, as it allows sharing of functions among application systems. 

An integrated health information system should support the business processes 
effectively. From this perspective, process integration (Sect. 3.8.6) is indeed the 
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overall vision of integration within heterogeneous information systems. Process 
integration is guaranteed when business processes are effectively supported by a set 
of interacting application systems. Systematic adoption of Integrating the Health 
care Enterprise (IHE) profiles is an indicator for structural quality on which smooth 
process integration can be achieved. Process integration is an important quality 
characteristic within heterogeneous health information systems, as it describes a 
situation where different application systems interoperate in an optimal way so that 
business processes are best supported. 


5.4 Evaluating the Quality of Health Information Systems 


Evaluation can be defined as the act of measuring or exploring components of a 
health information system. The result of an evaluation should provide information 
to support decisions concerning the health information systems, such as decisions 
regarding optimizing, replacing, or further deploying a component. 

This definition of evaluation highlights the fact that evaluation can comprise both 
quantitative (“measuring”) as well as qualitative (“exploring”) aspects and that eval- 
uation should answer a clear question and thus support management decisions of 
strategic or tactical management of information systems. Evaluation studies can, for 
example, help to justify IT investments, to verify that the information system is 
effective and safe, or to understand problems and to improve the information system. 

We will now discuss the basic phases of an evaluation study. We will see how to 
identify an evaluation question together with stakeholders, how to collect quantita- 
tive and qualitative data, and finally how to answer the evaluation question and how 
to use the evaluation results to improve the health information system. We will 
provide only a short introduction to this topic. Please consult specific textbooks to 
learn more about health IT evaluation (such as [3]). 


5.4.1 Identifying the Evaluation Question 


Evaluation studies of components of health information systems should answer a 
clear question and thus inform a decision. Such a decision may focus on ways to 
improve a component or the need to replace a component by another one. Identifying 
an evaluation question that is useful in a given situation is thus the first crucial step 
for any evaluation. 

Which evaluation question is useful depends on the context and especially on the 
adoption phase of the component. Adoption can be described as the successful inte- 
gration of an innovation in a health care facility. Adoption is a time-dependent 
process. 

The Clinical Adoption Metamodel [4] describes four dimensions of adoption of 
application systems that depend on each other: The first dimension of adoption is 
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“availability,” which comprises the ability of users to access the system, the avail- 
ability of the system, and the availability of content and features of the system. The 
second dimension of adoption is “system use,’ comprising the actual use of the 
system and the subjective user experience with the system. The third dimension of 
adoption focuses on “clinical behaviors” and comprises the meaningful adaptation 
of clinical processes to the system. The fourth dimension of adoption is reached 
when the new system has an impact on “clinical outcome” at the patient level, the 
provider level, or the population level. Combined, these four dimensions describe 
an adoption trajectory from first implementation of a new application system (or a 
specific feature of it) to changes in outcomes. 

This adoption model is helpful to identify the evaluation questions that are most 
relevant for given situation. In other words: Depending on the state of adoption of 
an application system, only specific evaluation questions are of relevance and make 
sense. For example, imagine that a health care facility has introduced a CPOE sys- 
tem for medication ordering with the aim to increase efficiency and quality of 
prescriptions. 


e In the adoption phase of “availability,” evaluation may focus on the following 
question: Is the CPOE system sufficiently made available to the intended user 
groups, for example, do all relevant users have a user account and are sufficient 
mobile tools for prescriptions available on all wards? Is the system available as 
planned, for example, are there no unplanned downtimes and is performance and 
stability as planned? Is all needed information available within the CPOE sys- 
tem, including patient administration data, prescription information, drug infor- 
mation databases, and interaction checks? Are all interfaces working as planned? 
Are the users sufficiently trained on the CPOE system, for example, have all 
physicians and nurses received sufficient training and support? 

e In the adoption phase of “system use,” evaluation may cover the following ques- 
tions: Is the CPOE system being used as intended by the various user groups, for 
example, are all prescriptions entered directly by the physicians into the CPOE 
system during ward rounds? Are all main features of the CPOE system being 
used as intended, for example, are interaction checks used at all? Do the users 
consider the system to be user-friendly? 

e In the adoption phase of “clinical behavior,’ evaluation will focus on the pro- 
cesses: Are the prescription processes efficiently supported by the system? How 
many automatic alerts of interaction checks occur, and are they considered and 
reacted upon by the clinical users? Did the overall number of prescriptions 
change after introduction of the CPOE system? 

e In the adoption phase of “clinical outcome,” evaluation will assess improvement 
in patient outcomes (e.g., reduction of medication errors, increase in patient 
safety) or costs (e.g., reduction of medication costs). 


Evaluation questions thus have to be properly chosen depending on the adoption 
phase of an application component and depending on the decision that is to be sup- 
ported by the evaluation, such as decision on further rollout, on further upgrades or 
other technical improvements before rollout, or on cancellation of a pilot project. 
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Given the usual constraints of time and money, an evaluation should focus on a 
limited set of evaluation questions and not try to answer too many questions. To 
increase the chance that evaluation focuses on an evaluation question that is useful 
to decision-makers, the decision-maker needs to be consulted when defining the 
evaluation question. 

Identification of the most relevant evaluation questions can be done, for example, 
in a workshop with the decision-maker, where the following questions could be 
discussed: 


e What is the object that should be evaluated, i.e., which application system or 
which feature should be evaluated? 

e What is the phase of adoption the application system is in at the moment? 

e Which decision are to be made regarding the application system and how can 
evaluation results help in this decision? 

e Which evaluation questions would provide the most crucial information? 


Such a workshop between the CIO, the medical director, and the evaluator, for 
example, could show that the CPOE system is already well adopted in one pilot 
department. It is now important to better understand the effect of the CPOE system 
on medication errors and patient outcome to be able to decide on further rollout. The 
major evaluation question will therefore be: “Does the CPOE system improve medi- 
cation safety?” 

After defining the evaluation questions, clear indicators need to be defined. For 
example, medication safety may be measured by counting prescription errors or 
adverse drug events or by looking at length of stay or mortality. Which indicator is 
best to answer a given evaluation question needs to be carefully decided based on 
the context, the available data, and the available scientific literature. 


5.4.2 Deciding on the Study Design 


Depending on the study question and considering the context of the study (e.g., 
available resources), the study design needs to be carefully chosen. Several types of 
study designs exist: 

First, we have to decide whether the study is planned as a quantitative study, a 
qualitative study, or a mixed-method study. Quantitative studies focus on collecting 
quantitative data (e.g., number of patient safety incidents or number of user logins) 
to answer the study question, while qualitative studies collect qualitative data (e.g., 
free text comments within surveys or user comments from interviews). Mixed- 
method studies combine quantitative and qualitative data. 

Second, we have to decide whether to conduct an exploratory study, a descriptive 
study, or an explanatory study. Explorative studies try to explore and describe a 
given situation, which means generating information to improve understanding of 
the situation. For example, an explorative study may try to find out the reasons for 
higher medication errors after introduction of a CPOE system. Explorative studies 
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are typically qualitative or mixed-method studies (i.e., they often apply open-ended 
observations or interviews). Descriptive studies focus on measuring a predefined 
attribute in a group of objects. For example, a descriptive study may measure user 
acceptance of CPOE systems or IT knowledge of the hospital staff. Descriptive 
studies are typically quantitative studies (1.e., they often apply a standardized survey 
or standardized observations). Finally, explanatory studies try to assess predefined 
hypotheses. For example, an explanatory study may test the hypothesis that intro- 
ducing a CPOE system significantly reduces medication errors in a given clinical 
setting. Explanatory studies are typically quantitative studies (i.e., they use quantita- 
tive measures to determine changes of the effect). 

Third, in case an explanatory study is planned, we have to decide whether to 
conduct it as an experimental study, a quasi-experimental study, or a non- 
experimental study. For experimental trials, the randomized controlled trial (RCT) 
is considered the gold standard with highest internal validity. By conducting an 
RCT, we can determine with a certain probability whether a given intervention (e.g., 
a CPOE system) led to a certain effect (e.g., a reduction of medication errors). 
Quasi-experimental study designs also try to assess a relationship between an inter- 
vention and an effect but have less internal validity compared to RCTs. Quasi- 
experimental designs are, for example, before-after trials or trials with a 
non-randomized control group. Both experimental trials and quasi-experimental 
trials are also called intervention studies, as they comprise a predefined interven- 
tion. Non-experimental studies (also called observational studies) also try to assess 
the relationship between an intervention and effect, but they do not intervene in any 
way, instead observing and collecting available (quantitative) data. They can be 
performed as cross-sectional studies (i.e., collecting data only at one point in time) 
or as longitudinal studies (i.e., collecting data at several points in time, for example, 
every 3 months). 

Fourth, we have to decide whether to conduct a laboratory study or a field study. 
In laboratory studies, we can better control the overall study setting, yet the external 
validity, i.e., the transferability of results to real settings, is limited. In field studies, 
it is more difficult to control the overall study settings, but external validity is higher. 


5.4.3 Collecting Quantitative Data 


Quantitative data comprise data that can be described by numbers. Numbers can 
easily be statistically analyzed, aggregated, and compared. The basic idea of quan- 
titative evaluation methods is that objects have attributes (such as duration or 
amount) that can be exactly measured. To obtain data representative for a predefined 
population, a sampling is selected and then analyzed. 

Typical quantitative evaluation methods comprise time measurements, quantita- 
tive observations, or quantitative surveys. 

Time measurements comprise time-motion analyses or work-sampling studies. 
The time-motion analysis is based on trained observers that measure the duration of 
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observed events (e.g., tasks) while using a predefined list of event categories. 
Typically, for time-motion analysis, one observer is needed for each observed actor 
(e.g., user), which is quite resource-intensive. This disadvantage is resolved by the 
work sampling analysis. Here, trained observers document which task is being exe- 
cuted only at predefined (e.g., every 5 min) or randomly selected time intervals. 
This allows them to observe several actors in parallel. By counting the number of 
observed tasks in each category, the overall distribution and thus the duration of 
each task can be calculated. To obtain precise numbers, however, this requires a 
relatively large number of observations to be done. Please note that both approaches 
(time-motion and work sampling) are typically conducted by trained external 
observers, though they can in principle also be conducted by the actors (e.g., users) 
themselves—this, however, may limit the quality of the data. 

Quantitative observations comprise observations of clinical situations or pro- 
cesses or the analysis of available data (e.g., log files) in which the number of events 
that occur in a given time period is counted by an observer. This can, for example, 
involve counting medication errors (based on an analysis of patient records), count- 
ing the number of clicks when using certain software, counting the number of physi- 
cian—patient interactions, or counting the number of patients entering a department. 
As for any measurement, special attention should be given to training the observers 
and to using standardized observation protocols to achieve inter-observer reliability. 

Quantitative surveys use standardized, closed questions that lead to quantitative 
results. For questionnaires addressing subjective opinions and feelings, the 5-point 
Likert scale is often used (“strongly agree’—“agree’—“neither agree nor 
disagree” —“disagree”—“‘strongly disagree”). The quality of data achieved by 
questionnaires depends on a thorough formulation of questions and predefined 
answer categories. Each questionnaire should be pretested. The available literature 
should thus be consulted before planning a questionnaire in order to ensure objec- 
tivity, reliability, and validity of results. If possible, available and validated ques- 
tionnaires should be reused. 


5.4.4 Collecting Qualitative Data 


Qualitative data comprises text and any other non-numerical data. Qualitative data 
can describe individual situations and contexts in quite some detail. Typical qualita- 
tive evaluation methods comprise qualitative interviews, qualitative observations, or 
qualitative content analysis. 

Qualitative interviews comprise all forms of semi- or unstructured interviews 
that use open questions, thus generating free text as a result. This allows the respon- 
dent to answer freely and allows interaction between interviewer and respondent. 
The interview can be conducted with one or more respondent at the same time. 
Group interviews support interaction between respondents but should only be done 
in groups without hierarchical dependencies. In any case, a pretested interview 
instruction is needed that describes how the interviewer should conduct the 
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interview and document the results. Answers are typically recorded by tape and 
later transcribed in verbatim or aggregated protocols. The data can be analyzed 
using qualitative content analysis, for example. 

Qualitative observations comprise open, less-standardized, non-quantitative 
observations of processes or events. Contrary to quantitative observations, the aim 
is not to count and measure, but to obtain deeper insight into a situation. The obser- 
vations are typically documented in a field diary or on predefined observation pro- 
tocols. Qualitative observations generate text (such as observer notes) that can be 
analyzed using qualitative content analysis. Please note that for qualitative observa- 
tion, there should be a certain familiarity of the observer with the observed field 
(e.g., with the situation in the clinical department). 

Qualitative content analysis is used to analyze text that obtained from qualitative 
interviews or qualitative observations. Qualitative content analysis is a methodolog- 
ical, planned approach for grouping qualitative data into categories. Here, the mate- 
rial is analyzed stepwise and coded into several available categories. The categories 
can either be defined beforehand (deductive approach), developed while reading 
and analyzing the text (inductive approach), or defined beforehand and refined 
while analyzing the text (mixed approach). The coding of text into categories should 
be reproducible; it must therefore be clearly documented and explained with the 
so-called anchor examples. Typically, the text material is read and coded more than 
once to make sure that nothing is overlooked and that the categories are homoge- 
neous and all filled with text examples. Based on the categories and the text pas- 
sages that are related to them, the text can then be further analyzed to identify larger 
patterns and to answer the study questions. 


5.4.5 Answering the Evaluation Questions 


If an evaluation was carefully planned, the collected quantitative and qualitative 
data should now allow the previously defined evaluation question to be answered. 
For example, a pre-post study of prescription errors showed that prescription errors 
were largely reduced by the CPOE system. This result motivates further rollouts. 

Evaluation results may help to improve the quality of the information system, for 
example, the quality of integration (Sect. 5.3). Evaluation studies that aim mostly at 
collecting data to improve an information system are also called formative evalua- 
tion studies. Formative evaluation studies often take place in early phases of adop- 
tion. For example, a typical formative evaluation assesses whether users are using a 
CPOE system as intended by conducting qualitative observations to identify if there 
is need for further user training. Results of formative evaluation will thus help to 
decide on needs for improvement in technology, processes, or training. 

Evaluation results may also answer the question whether the application system 
has achieved its intended goals. These evaluations typically focus on a certain out- 
come of a component and take place in later adoption phases. These types of evalu- 
ation studies are also called summative evaluation studies. For example, a typical 
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summative evaluation assesses whether the CPOE system has improved medication 
safety after | year of using the CPOE system by applying quantitative chart analy- 
sis. The results of summative evaluation will help to justify the expenses of the 
CPOE system and motivate further rollout. 


5.5 Examples 


5.5.1 Unintended Effects of a Computerized Physician Order 
Entry Nearly Hard-Stop Alert 


The introduction of application systems may have unintended effects. The careful 
evaluation of impact and unintended effects of application systems is thus an impor- 
tant task of management of information systems. We will now have a look at an 
example of an evaluation study that showed some unintended effects of CPOE 
systems. 

Table 5.1 presents the abstract of an RCT on automatic alerts ina CPOE system. 
The authors analyzed whether the so-called hard-stop alert can reduce unwanted 
drug—drug interactions. Such a “hard-stop alerts” appears on the screen to alert the 
physician about potential problems associated with a particular prescription and 
blocks the clinician’s order from further execution to avert potentially serious 
reactions. 


Table 5.1 Abstract from “Unintended Effects of a Computerized Physician Order Entry Nearly 
Hard-Stop Alert” [5] 


Background: The effectiveness of CPOE systems has been modest, largely because clinicians 
frequently override electronic alerts 


Methods: To evaluate the effectiveness of a nearly “hard-stop” CPOE system prescribing alert 
intended to reduce concomitant orders for warfarin and trimethoprim-sulfamethoxazole, a 
randomized clinical trial was conducted at two academic medical centers in Philadelphia, 
Pennsylvania. A total of 1981 clinicians were assigned to either an intervention group receiving 
a nearly hard-stop alert or a control group receiving the standard practice. The study duration 
was August 9, 2006, through February 13, 2007 

Results: The proportion of desired responses (i.e., not reordering the alert-triggering drug within 
10 min of firing) was 57.2% (111 of 194 hard-stop alerts) in the intervention group and 13.5% 
(20 of 148) in the control group (adjusted odds ratio, 0.12; 95% confidence interval, 0.045— 
0.33). However, the study was terminated early because of four unintended consequences 
identified among patients in the intervention group: a delay of treatment with trimethoprim- 
sulfamethoxazole in two patients and a delay of treatment with warfarin in another two patients 


Conclusions: An electronic hard-stop alert as part of an inpatient CPOE system seemed to be 
extremely effective in changing prescribing habits. However, this intervention precipitated 
clinically important treatment delays in four patients who needed immediate drug therapy. 
These results illustrate the importance of formal evaluation and monitoring for unintended 
consequences of programmatic interventions intended to improve prescribing habits 
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The study was designed as a quantitative, explanatory field study that was con- 
ducted as an RCT. The study found that these alerts can help to reduce the number 
of alert-triggering orders. But it also found that the hard-stop alert led to clinically 
important treatment delays in four patients. 


5.5.2 Clinical Decision Support for Worker Health: A Five-Site 
Qualitative Needs Assessment in Primary Care Setting 


Besides evaluating the effect of an intervention, evaluation may also try to under- 
stand reasons for successful or unsuccessful implementation of an application sys- 
tem. For these kinds of questions, qualitative studies are often chosen. 

Table 5.2 presents the abstract of such a qualitative study. The authors analyzed 
need, barriers, and facilitators for clinical decision support (CDS) in primary care. 
The study was performed as a qualitative, exploratory field study. 

The authors found several factors that may hinder or foster the use of CDS in 
primary care. The results of this multi-center study can now be used to implement 
CDS in commercial application software products for primary care. 


Table 5.2 Abstract from “Clinical Decision Support for Worker Health: A Five-Site Qualitative 
Needs Assessment in Primary Care Settings.” [6] 


Background: Although patients who work and have related health issues are usually first seen in 
primary care, providers in these settings do not routinely ask questions about work. Guidelines 
to help manage such patients are rarely used in primary care. Electronic health record systems 
(EHRS) with worker health CDS tools have potential for assisting these practices 


Objective: This study aimed to identify the need for and barriers and facilitators related to 
implementation of CDS tools for the clinical management of working patients in a variety of 
primary care settings 


Methods: We used a qualitative design that included analysis of interview transcripts and 
observational field notes from 10 clinics in five organizations 


Results: We interviewed 83 providers, staff members, managers, informatics and IT experts, and 
leaders and spent 35 h observing. We identified eight themes in four categories related to CDS 
for worker health (operational issues, usefulness of proposed CDS, effort and time-related 
issues, and topic-specific issues). These categories were classified as facilitators or barriers to 
the use of the CDS tools. Facilitators related to operational issues include current technical 
feasibility and new work patterns associated with the coordinated care model. Facilitators 
concerning usefulness include users’ need for awareness and evidence-based tools, 
appropriateness of the proposed CDS for their patients, and the benefits of population health 
data. Barriers that are effort-related include the additional time the proposed CDS might take as 
well as other pressing organizational priorities. Barriers that are topic-specific include sensitive 
issues related to health and work and the complexities of information about work 


Conclusion: We discovered several themes not previously described that can guide future CDS 
development: technical feasibility of the proposed CDS within a commercial electronic health 
record (EHR), the sensitive nature of some CDS content, and the need to assist the entire health 
care team in managing worker health 
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5.5.3 Certification of Health Information Systems 


There exist several national and international approaches for certification of appli- 
cation software products to be used in health care, such as the European CE certifi- 
cation, the German digital health application (DiGA) repository, the ONC Health IT 
Certification Program in the U.S. and IHE Connectathons. 

CE certification is mandatory in the European Union for all application software 
products developed to be used for medical purposes such as diagnosis, prevention, 
monitoring, or prognosis. For example, a software calculating the correct amount of 
insulin needed is considered a medical device and thus needs CE certification. CE 
certification assures that the software complies with all European legal require- 
ments regarding safety, health, and environment. Depending on the risk class that 
the application software product belongs to, certification can be done by the manu- 
facturer of the software or it must be done through external auditing. Details on CE 
certification are available in the EU’s Medical Device Regulation 2017/745 [7]. 

The German DiGA repository for “health applications” [8] is maintained by the 
Federal Institute for Drugs and Medical Devices and lists health apps that fulfill a 
set of quality requirements. Besides being CE-certified as a medical device of a low- 
risk class, the application must be actively used both by the patient and by a health 
care provider and must fulfill certain data protection and information safety require- 
ments. In addition, the vendor must provide supporting evidence (e.g., from evalu- 
ation studies) about the positive effect of the health application on the quality of 
patient care. When listed in the DiGa repository, health applications can be pre- 
scribed by a physician and are reimbursed by the patient’s health insurance company. 

In the United States, the Health IT Certification Program is operated by the Office 
of the National Coordinator for Health Information Technology (ONC) [9]. To be certi- 
fied, a vendor of acomponent must fulfill a number of requirements that assess whether 
an application software product supports clinical processes, care coordination, privacy 
and security, patient engagement, and exchange and interoperability of patient data. 
Part of certification is the annual testing of the component in real-world settings. 

The IHE initiative [10] (Sects. 3.7.2.5 and 3.7.2.6) strives to increase interoper- 
ability between components based on existing standards such as HL7 and DICOM 
(Digital Imaging and Communications in Medicine). IHE offers testing for the 
standards-based interoperability between components in the so-called 
Connectathons. During a Connectathon, components of different vendors exchange 
information with other components in a supervised environment. The Connectathon 
provides detailed validation of the components’ interoperability and compliance 
with IHE profiles. The results of testing are published by IHE. 

Besides certification of quality and interoperability of software, health care facil- 
ities or vendors can strive for certification of the quality of their internal processes 
by applying for ISO certifications or for the Joint Commission certification. 

The ISO 9001 standard [11] defines criteria for the quality management system 
of an organization. An ISO 9001 certificate states that an organization follows cer- 
tain formalized quality processes, that it monitors the outcome of its processes, and 
that it facilitates their continuous improvement. 
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The ISO 27001 standard [12] focuses on information security management. An 
ISO 27001 certificate states that an organization has an established information 
security management system and is able to manage the security of information, such 
as employee information, patient information, or financial information. 

The Joint Commission [13] is a US-based organization assessing health care 
organizations and programs based on preestablished quality standards. A subset of 
its standards focuses on management of information systems and addresses issues 
such as data privacy, information security, standardization of data collection, and 
interoperability of data. 


5.6 Exercises 


5.6.1 Quality of Integration 


Read the following case descriptions and discuss the integration problems using the 
types of integration presented in Sect. 5.3.4. Which negative effects for information 
logistics result from the identified integration problems? 


1. A physician enters a medical diagnosis for a patient first in the medical docu- 
mentation and management system (MDMS) and later, when ordering an X-ray, 
again in the CPOE system. 

2. The position of the patient’s name and the formatting of the patient’s birthdate 
vary between the MDMS and the CPOE system. 

3. When physicians shift from the MDMS to the CPOE system, they have to log in 
again and again search for the correct patient. 

4. The CPOE system and the RIS use slightly different catalogs of available radiol- 
ogy examinations. 

5. When physicians write the discharge letter for a patient in the MDMS, they also 
have to code the discharge diagnosis of a patient. For this coding, they have to 
use a feature that is only available in the patient administration system, so they 
have to shift to this application system. 

6. While at the patient’s bedside during their ward rounds, physicians have to use 
several application components at the same time, such as MDMS for retrieving 
recent findings, the CPOE system for ordering, and the PACS for retriev- 
ing images. 


5.6.2 Data Collection in Evaluation Studies 


Read Examples 5.5.1 and 5.5.2 and determine which methods for collecting data (as 
described in Sects. 5.4.3 and 5.4.4) have been used. 
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5.6.3 Study Design in Evaluation Studies 


Read Examples 5.5.1 and 5.5.2 and describe the chosen study design in more detail, 
using the description presented in Sect. 5.4.2. 
Try to explain for which types of study questions the RCT is the best study design. 
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Chapter 6 A) 
Information Systems for Specific Health gest 
Care and Research Settings 


6.1 Introduction 


In Chaps. 3 and 4, we introduced health information systems and two perspectives 
when dealing with them: the technological perspective and the management per- 
spective. Using the technological perspective, we describe the architecture and inte- 
gration of an information system. Using the management perspective, we describe 
the strategic, tactical, and operational management of an information system. 

In this chapter, we will now refer to these perspectives with respect to specific 
health care settings. Please recall Chap. 1 where life situations and their relative 
share of health care were introduced. The following institutional health care settings 
were mentioned in particular: 


e In hospitals, patients with acute and chronic diseases or in an emergency situa- 
tion receive inpatient and, partially, outpatient treatment. 

e In nursing homes, persons receive care. 

e In medical offices, patients with acute and chronic diseases receive outpatient 
treatment. 

e Ambulatory nursing organizations take care of persons in their homes. 


Each health care setting thus has a specific role in providing health care and is 
related to specific life situations. This specific role corresponds to specific struc- 
tures, processes, and stakeholder groups in these different health care settings. Not 
surprisingly, the information systems of these health care settings also show typical 
differences both from a technological and from a management perspective that we 
want to explore further in this chapter. 
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Besides discussing information systems in these institutional health care set- 
tings, we will also address information systems for medical research facilities as 
well as transinstitutional information systems in regions or in states. We will also 
discuss how personal environments such as homes can be considered for health care 
(Fig. 6.1). 

For most of these health care settings, you will first be introduced to their char- 
acteristics, such as their activities, areas, and persons. Then we will describe their 
specific technological and management perspectives, building on Chaps. 3 and 4. 

As mentioned in Chap. 1, health care organizations can vary from country to 
country. Therefore, the characteristics described here, as well as their technological 
and management perspectives, may also differ to some extent from country to 
country. 

Please also recall the definitions of “information system” and “health informa- 
tion system” in Chap. 2 with respect to specific health care settings. Let us take 
hospitals as an example of such health care settings: Hospital information systems 
are the socio-technical subsystem of hospitals, which comprise all data, informa- 
tion, and knowledge processing as well as the associated human or technical actors 
in their respective data, information, and knowledge processing roles. The same 
holds accordingly for other health care settings mentioned in this chapter. 

After reading this chapter, you should be able to 


Fig. 6.1 Health information systems constitute an essential part of providing good health care. 
Patient with shoulder pain trains at home with an autonomous rehabilitation system 
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e describe characteristics of different health care settings, 

e explain the resulting implications for the technologies used and the management 
of information systems in these health care settings, and 

e explain the differences of specific health information systems and their 
management. 


Please note that the terms highlighted in italics are terms from the glossary or 
represent functions or application system types. 


6.2 Information Systems in Hospitals 


6.2.1 Characteristics of Hospitals 


Hospitals are settings where patients with acute and chronic diseases or in an emer- 
gency situation receive inpatient and, partially, outpatient treatment. 

Areas of hospitals to be considered by hospital information systems are wards, 
outpatient units, service units (e.g., diagnostic units such as laboratory and radiology 
departments, therapeutic units such as the operation room, and other units such as 
pharmacy, patient records archive, library, blood bank), hospital administration 
areas (e.g., patient administration department, department of quality management, 
financial and controlling department, department of facility management, informa- 
tion management department, general administration department, human resources 
department), offices, and writing services for (clinical) report writing. In addition, 
there are the management areas, such as hospital management, management of clini- 
cal and non-clinical departments, administration management, and nursing manage- 
ment. These areas are related to patient care. They could be broken down further. 
For university medical centers, additional areas for research and education must be 
added to the above list. 

The most important persons in a hospital are, obviously, patients. Important 
groups of persons working in a hospital are physicians, nurses, administrative staff, 
technical staff, medical informaticians, and health information management staff. 
Within each group of persons, different needs and demands on the hospital informa- 
tion system may exist depending on the role, tasks, and responsibilities. Ward physi- 
cians, for example, require different information than physicians working in service 
units or senior physicians. Patients sometimes need similar information as physi- 
cians but in a different form. 


6.2.2 Technological Perspective 


Hospitals can be considered as quite complex institutional health care settings. 
Therefore, nearly all functions mentioned in Chap. 3, together with their data to be 
processed, have to be considered, as well as many of the application components, 
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nearly all of which can be part of a hospital information system. The examples in 
Chap. 3 were often taken from hospitals because of this fact. Consequently, integrity 
and integration are especially crucial when managing hospital information systems. 


6.2.3 Management Perspective 


As hospitals are such complex entities, there are many different stakeholder groups 
with sometimes conflicting requirements regarding the hospital’s information sys- 
tem. These stakeholder groups include the various professional groups (physicians, 
nurses, administrators, researchers, teachers, etc.). In this situation, systematic 
information management and a carefully planned step-by-step approach of shaping 
the information system are essential. Thus, all tasks and methods presented in Chap. 
4 have to be considered by the management of the information system. Due to the 
same reason, most examples in Chap. 4 were taken from hospitals. 


6.3 Information Systems in Nursing Homes 


6.3.1 Characteristics of Nursing Homes 


Nursing homes are organizations primarily related to the care of persons with physi- 
cal and mental functional deficits. These are often, but not exclusively, senior citi- 
zens at an advanced age. They are usually called residents. 

The most important working areas in nursing homes are the wards and the resi- 
dents’ rooms, the administration areas, and the management areas (especially nurs- 
ing management). Depending on their specialty, nursing homes may have dedicated 
areas for therapeutic services. Nursing homes can be of very different size, ranging 
from a few to hundreds of beds. 

The most important persons in a nursing home are, obviously, the nursing home 
residents. In addition, the visitors are also of great importance and special amenities 
and services are provided for them as well. Important groups of persons working in 
a nursing home are nurses as well as administrative and management staff. 


6.3.2 Technological Perspective 


In nursing homes, the functions to be performed are mainly those of nurses and 
administrative staff. The typical application component is the nursing management 
and documentation system (NMDS) that supports major functions such as patient 
administration, decision-making, planning, organization of patient treatment, and 
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coding. In the event that external physicians or other specialists are involved in 
patient care, they may also document their findings in the NMDS. Otherwise, they 
may use their own application system for documentation (such as the application 
system of the general practitioner (GP)). In the latter case in particular, but also in 
order to be able to receive prescriptions and findings from specialists and laborato- 
ries, for example, communication links from the NMDS to application systems out- 
side the nursing home are required. The interoperability standards and integration 
technologies from Chap. 3 can be used for this purpose. A prerequisite, however, is 
the physical integration discussed in Sect. 3.10.2 based on a secure data transmis- 
sion connection at the physical tool layer. 


6.3.3 Management Perspective 


Management of information systems in nursing homes is typically reduced. Often, 
senior nursing managers will be responsible for organizing management of informa- 
tion systems. Sometimes, they may be supported by the vendor of the NMDS which 
delivers and maintains the software and sometimes the hardware. 

The aforementioned requirements of the technology, particularly with regard to 
the necessary external communication, also lead to special challenges in the area of 
data security. In particular, if the nursing home, unlike a hospital, does not have its 
own professional information managers, the management of the home must take 
strict care to ensure that the tasks of professional and systematic information man- 
agement are nevertheless covered. It is a good idea to outsource the corresponding 
services to specialized external companies. But even such a solution does not relieve 
the home management of its responsibility for the information system. 


6.4 Information Systems in Medical Offices 


6.4.1 Characteristics of Medical Offices 


Medical offices are settings where patients with acute and chronic diseases receive 
outpatient treatment. 

The most important working areas in medical offices are the examination and 
treatment rooms. Further areas for patients that we must consider are waiting areas 
with, for example, waiting rooms. All this is similar to outpatient units in hospitals. 
In addition, areas for administrative purposes, for example, patient management, 
billing, and telephone services, can often be found in medical offices. Depending on 
their specialty, medical offices (in particular specialist offices) may have additional 
areas for diagnostic or therapeutic services. 
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As in hospitals, the most important persons in medical offices are patients. The 
three groups of persons usually working in medical offices are physicians, other 
health care professionals (e.g., nurses, laboratory staff, psychologists, physiothera- 
pists), and administrative staff. Whereas hundreds or thousands of health care pro- 
fessionals work in hospitals, the number of persons working in medical offices is 
much lower, often less than 10. Information systems for medical offices have to 
support these persons’ needs. Obviously, the complexity of information systems of 
medical offices is less than the one of the hospitals. 


6.4.2 Technological Perspective 


In medical offices, the functions to be performed are mainly those of health care 
professionals and of administrative staff with regard to patient care and administra- 
tion. As in other settings, application systems are needed which support functions 
such as patient administration, decision-making, planning, organization of patient 
treatment, and coding. Typically, a patient administration system and a medical 
documentation and management systems (MDMS), both based on software from a 
single vendor, are combined into a single application system. The result is similar to 
the clinical information system (CIS) and electronic health record system (EHRS) 
discussed in Sect. 3.4.15. In the case of specialist medical offices with additional 
areas for diagnostic or therapeutic services, additional application systems for these 
functions can be found, for example, a radiology information system (RIS) together 
with a picture archiving and communication system (PACS) or laboratory informa- 
tion system (LIS). If so, integration of these application systems in the office is 
needed as discussed in Chap. 3. 

Medical offices exchange a wide range of information with nursing homes, labo- 
ratories, hospitals, specialists, and other care facilities. Therefore, secure interfaces 
for external communication must also be provided for its application systems 
(Chap. 3). 


6.4.3 Management Perspective 


Medical offices are sometimes independent “small enterprises”. Other times, they 
are part of a larger health care facility. Medical offices are even smaller than nursing 
homes and can hardly have their own information management staff. If the medical 
offices are independent enterprises, however, they still need to take responsibility 
for the information management. Ensuring data security in particular must not be 
neglected under any circumstances. The owner or the management of the medical 
office will then be responsible for the management of the information system, 
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sometimes supported by consulting companies, which also deliver and maintain 
hardware and application software products for application systems in these offices. 
If the medical offices are part of a larger health care facility, information manage- 
ment is usually handled by the IT departments of these facilities. 


6.5 Information Systems in Ambulatory 
Nursing Organizations 


6.5.1 Characteristics of Ambulatory Nursing Organization 


Ambulatory nursing organizations are primarily related to the care of persons with 
physical and mental functional deficits living at home. These are often, but not 
exclusively, senior citizens at an advanced age that are visited regularly by ambula- 
tory nurses. 

The most important working areas therefore are the patients’ homes as well as an 
administrative office area where the visits are coordinated. The most important per- 
sons working for ambulatory nursing organizations are nurses, supported by admin- 
istrative and management staff. Ambulatory nursing organizations can be of very 
different size, from a few to hundreds of nurses. 


6.5.2 Technological Perspective 


Ambulatory nursing organizations need support for the overall coordination and 
organization of the visits at the patients’ homes as well as for nursing management 
and documentation, done mostly at the patients’ bedside, and for administration and 
billing. The respective functions are compiled in Table 3.3. 

Ambulatory nursing organization may use an NMDS that also offers special fea- 
tures for organization and coordination of visits at patients’ home. At the physical 
tool layer, mobile tools are often used to facilitate information processing at the 
patients’ homes when using the NMDS. 


6.5.3 Management Perspective 


As for medical offices, ambulatory nursing organizations may be small enterprises 
or part of larger organizations. Management of information systems in ambulatory 
nursing organizations depends on the size of the organization here as well. The 
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owner or the management of the organization will then be responsible for the man- 
agement of the information system. Sometimes, they may be supported by the ven- 
dor of the NMDS which delivers and maintains the software and sometimes the 
hardware as well. 


6.6 Information Systems in Medical Research Facilities 


6.6.1 Characteristics of Medical Research Facilities 


Medical research facilities exist in a variety of shapes and with different character- 
istics. Medical research is conducted at university medical centers, for example, in 
specialized working groups, institutes, or sub-units, but may also be conducted in 
universities, associated institutes, or industrial facilities, for example, in the phar- 
maceutical industry. Medical research usually is interdisciplinary and involves het- 
erogeneous data on various entity types, for example, “clinical trial,” “finding,” or 
“classified diagnoses” (Sect. 3.2.3.4). Especially in academic centers, efficient 
research and education must be supported. The objective of clinical research is the 
generalization of findings and experiences to gain new knowledge. Data docu- 
mented during the patient treatment process may be reused for retrospective analy- 
sis to find evidence for generalization and to generate hypotheses for new studies. 


6.6.2 Technological Perspective 


Research facilities are very different from patient care facilities in terms of the func- 
tions to be performed and also in terms of the application systems to be used. For 
this reason, we will discuss both the specific functions and the application systems 
in more detail below. The following specific information processing functions need 
to be supported (Fig. 6.2). 

Experiments and clinical trials are important for the progress in medicine because 
they update biomedical and health knowledge. Scientific staff must be supported in 
planning, executing, and analyzing studies and experiments. Planning and execu- 
tion must conform to legal requirements. For example, patients have to be informed 
of opportunities and risks before they can consent to taking part in a clinical trial. 
Data documentation needs to fulfill the de facto standard of minimal requirements 
for managing research data, the FAIR criteria for research data management: find- 
able, accessible, interoperable, and reusable. Significant progress in research, for 
example, in generating new hypotheses for later prospective studies or by uncover- 
ing new pathomechanisms or pathways associated with diseases, is also achieved 
through retrospective analysis of large amounts of heterogeneous data. These data- 
driven scientific approaches must also be supported by research facilities. 
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Fig. 6.2 Extract of the domain layer of the 3LGM?-based reference model describing the function 
research and education, its subfunctions and interpreted and updated entity types 


Finally, for research data, processes of pseudonymization and/or anonymization 
must be supported wherever necessary in order to conform to legal requirements. 

Scientific staff needs to prepare publications and presentations. Therefore, cen- 
tral collections of both the facility’s relevant publications and other literature need 
to be made available to them using a standardized interface. Scientific staff needs 
access to research-relevant information and general medical knowledge. 

Medical casuistic and treatment data must be made available for training and 
education in medical professions. Furthermore, the organization and execution of 
teaching and exams, for example, through e-learning tools and tools for taking elec- 
tronic exams, must also be supported. 

Research management is executed in all of the hospital’s organizational units 
which decide on planning, monitoring, and directing research activities. This 
includes the documentation of research activities as well as the management of 
third-party funds and the management of scientific sub- or service units within 
facilities. 

To implement the above-mentioned functions, numerous different application 
components usually exist. Frequently, medical research facilities run multiple 
decentralized database systems or repositories for specific research purposes, proj- 
ects, or trials. Clinician scientists often call these “cohort” databases, reflecting the 
longitudinal or cross-sectional nature of data capture. Dedicated research data man- 
agement offices support researchers in creating such data repositories or registries 
in accordance with FAIR criteria by consulting them in terms of how to plan, 
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conduct, and document research projects and by supporting them in selecting stan- 
dards for structuring, representing, and saving their data along with appropriate 
metadata, thus aiming for a certain degree of interoperability and reusability. 

For clinical trials which have to fulfill very high standards with regard to data 
quality, data monitoring, versioning, etc., dedicated electronic data capture (EDC) 
systems are used. These offer customizable data entry forms and various export 
formats, most notably using CDISC standards (Sect. 3.7.2.11). 

Data from clinical application systems which are provisioned for reuse in 
research are frequently stored in data warehouse systems (DWS), data lakes (reposi- 
tories for raw, often unstructured data), or open platforms (Fig. 6.3). If the facility 
does not run an open platform, all of the above require some sort of export (e.g., as 
Health Level 7 (HL7) messages, HL7 FHIR) or extraction process from clinical 
application systems. While data lakes incorporate raw data such as files, blobs, or 
genomic sequences, DWS, as invariant systems for research, require an extract, 
transform, load (ETL) process, during which quality checks, and mapping to termi- 
nologies may be performed. Open platforms, in contrast, provide care-level, longi- 
tudinal patient-related data of the highest quality and semantic definition, so that 
clinical or research applications as well as registries can be built upon them. For 
research purposes, a research copy of the EHR with pseudonyms may be used. 

With rising needs of cross-institutional or international research collaboration, 
data sharing, and integration, many medical research facilities establish central 
units called data integration centers (DIC). They integrate data and run all systems 
that enable cross-institutional querying and data exchange, while at the same time 
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taking care of use-and-access processes and their documentation, data protection 
and safety, consent management, and all activities related to data integration and 
semantic enhancement (e.g., terminology binding). 

Medical research requires a great deal of creativity, and the application and data- 
base systems used must be flexibly adaptable to new research questions being inves- 
tigated. Therefore, it is necessary to enforce the use of open standards for data 
representation, so that the data are reusable in future projects and in different con- 
texts. Likewise, open interfaces and standardized query languages are necessary for 
data access. This facilitates rapid and flexible software development for research. 

Systems for research often demand huge storage capacity as well as adequate 
network bandwidth, particularly in the disciplines concerned with omics (e.g., in 
metabolomics) or imaging data. Research organizations must anticipate future stor- 
age needs and provide adequate physical storage systems as well as highly perfor- 
mant computing infrastructures for extensive analyses of large and heterogeneous 
datasets. For this purpose, facilities frequently run their own high-performance 
computing clusters, including special GPU (graphics processing unit) systems. 
Employing cloud solutions may also be useful to share computing capacities with 
other research facilities. 

Medical research is also dependent on international cooperation, which requires 
even more flexible options for digital communication beyond the boundaries of the 
facility than is necessary for health care facilities. When research facilities are part 
of a health care facility, the physical data processing systems of the research facility 
are therefore connected in a separate part of the communication network that is 
strictly separated from the communication network of the health care facility. 


6.6.3 Management Perspective 


Information systems in medical research facilities demand dedicated and special- 
ized management for optimal support of research endeavors. To fulfill FAIR criteria 
and in particular to enable data reuse and sharing within and across facilities, it is 
crucial to avoid home-made research infrastructures (e.g., using spreadsheets or 
proprietary databases) which are not or only partly interoperable with other sys- 
tems. From a management perspective, it is crucial to define and enforce rules, 
processes, and standards for representing, storing, and sharing research data. To 
achieve this, dedicated research data management units can provide consultation 
and support for researchers, at the same time supervising a coherent management 
strategy. If they exist, these units may work closely together with DICs. 

Strategic planning and establishing a strategic information management plan is 
particularly challenging in research institutions for two reasons. Firstly, it is difficult 
to foresee which research questions will have to be addressed in 5 years’ time. As a 
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result, the application systems required for this purpose can also be predicted less 
well than in health care facilities. It is therefore necessary to plan primarily for 
generic tools and also software development groups in order to be able to adapt 
quickly to new research questions. Secondly, research is often funded on a project 
basis. Thus, it is often only known at fairly short notice what funding is available for 
the procurement of software and hardware; for the long-term maintenance and ser- 
vicing of components, the necessary funds can often only be made available on an 
ad hoc basis. Consequently, a strategic information management plan will tend to 
provide a broad framework for the development of the research institution’s infor- 
mation system and focus on infrastructure (Sect. 2.11). 


6.7 Information Systems in Other Health care Settings 


In addition to the institutional health care settings already mentioned, there are a 
number of other institutions involved in health care services for people. These 
include: 


e pharmacies, 

e medical supply stores, 

e therapeutic offices, 

e inpatient and outpatient rehabilitation facilities, 
e hospices, 

e wellness facilities, and 

e sports centers and leisure parks. 


6.7.1 Characteristics of Other Health care Settings 
6.7.1.1 Pharmacies 


Pharmacies are settings where persons with acute or chronic diseases or for preven- 
tive purposes can obtain prescription-only or non-prescription medications as well 
as medical aids. 

A pharmacy usually consists of three areas. The free-dial area refers to the sales 
area in front of the counter where non-pharmacy products are offered, such as band- 
aids, toothpaste, and teas. The area behind the counter, which is clearly visible to all 
customers, is called the sight-selection area. Here, a person will find pharmacy-only 
products that can be purchased without a prescription, such as light pain analgesics, 
cough syrups, or nasal spray. In the last area, the pharmacy warehouse, which is 
usually structurally separated from the sales area, prescription-only medications are 
stocked in special shelving systems and pharmacy lockers. 
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Many different professional groups are employed in pharmacies. The most 
important people working in pharmacies are pharmacists. They are the experts on 
medicines and are responsible for, among other things, the production and dispens- 
ing of medicines and advising patients. Every pharmacy must have at least one 
pharmacist on site at all times. In addition, there are a number of pharmaceutical 
personnel, such as pharmaceutical technical assistants, pharmacist assistants, and 
pharmaceutical assistants. However, non-pharmaceutical personnel also operate in 
pharmacies. These include pharmaceutical commercial assistants, pharmacy assis- 
tants, and skilled pharmacy workers. 


6.7.1.2 Therapeutic Offices 


There is a variety of different therapeutic offices that provide (therapeutic) treat- 
ment for people in the outpatient sector. These include offices for physical therapy, 
physiotherapy, occupational therapy, speech therapy, and massage therapy. In addi- 
tion to the relief of physical complaints, however, there are also therapeutic offices 
for relieving mental complaints, such as psychotherapists or learning therapists. 

Therapeutic offices, similar to medical practices, consist of a waiting area, a 
registration area with a reception desk, and one or more treatment rooms. The 
equipment of the individual treatment rooms depends on the therapeutic measures 
to be performed. Depending on the range of services provided by a facility, there 
may also be additional areas for specific therapeutic services. In physiotherapy 
practices, for example, it is not uncommon to find individual equipment areas for 
performing physiotherapy exercises. 

Alongside patients, therapists are the most important professional group in thera- 
peutic practices. Depending on the specialization of a therapeutic office, these 
include masseurs, physiotherapists, occupational therapists, or respiratory, speech, 
and voice teachers. The tasks to be performed vary considerably depending on the 
professions, but usually include both advanced diagnostics and therapy. 

Quite often, medical assistants also work in therapeutic practices. They take on 
administrative and supporting activities. 


6.7.1.3 Inpatient and Outpatient Rehabilitation Facilities 


There are both outpatient and inpatient rehabilitation facilities of all sizes. 
Rehabilitation facilities are settings in which patients with a health condition are 
enabled “to remain in or return to their home or community, live independently, 
and participate in education, the labor market and civic life” [1]. For this purpose, 
rehabilitation facilities often focus on a specific discipline. For example, there 
are rehabilitation centers specialized in cardiological, neurological, or orthopedic 
rehabilitation. 
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Inpatient rehabilitation facilities, also called rehabilitation centers, are compa- 
rable to hospitals. Thus, there are also different wards and service areas which must 
be supported by an information system: patient rooms, community areas, treatment 
areas for individual and group therapy, administrative areas (e.g., patient adminis- 
tration department, financial and controlling department), and also a kitchen/ 
canteen. 

Outpatient rehabilitation centers are comparable to therapeutic offices, only that 
they are larger and usually offer a wider range of functions. 

The most important people in rehabilitation facilities are the patients. Among the 
most important employees are the medical staff as well as various therapists (e.g., 
occupational therapists, speech therapists, and physiotherapists), nurses, and social 
workers. Alongside the medical-therapeutic staff, there are also a large number of 
employees in administrative areas, for example, typists, therapy planners, and 
receptionists. On top of this, there are various service employees, such as house- 
keepers and kitchen staff. The number of employees per facility strongly depends 
on the size and scope of the services provided. 


6.7.1.4 Hospices 


Hospices focus on the palliative care of critically ill patients and of persons passing 
away. Apart from relieving pain and enhancing the individual’s quality of life in 
their final phase of life, the tasks also include providing bereavement services for 
relatives. In addition to inpatient hospices, there also are outpatient hospice services 
that provide support for patients and relatives in their own homes or in an inpatient 
care facility. 

Inpatient hospices are relatively small (8—16 beds) and consist of areas similar to 
inpatient care facilities. Alongside the patients’ rooms, hospices also have a recep- 
tion area, administration, community rooms, guest rooms for relatives, staff rooms, 
and a kitchen. 

Hospice care is provided by an interdisciplinary team. Alongside nursing staff 
with an additional palliative qualification (palliative care nurse), chaplains, psy- 
chologists, and social workers, hospice volunteers with training as assistant dying 
companions are also among the most important employees of hospices. There are 
also administrative staff and housekeepers. The number of nursing staff in a hospice 
depends on the number of beds available. In Germany, there is a care contract for 
inpatient hospice care that contains corresponding indications. Hospices, like inpa- 
tient nursing homes, do not have their own medical staff. Medical care is provided 
by physicians from general practices (primary care physicians) or from attached 
hospitals. 
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6.7.1.5 Wellness Facilities 


Especially in the context of tertiary prevention, certain facilities play a role that one 
would not necessarily think of first in the context of a health care setting. For exam- 
ple, various wellness activities to increase well-being and relaxation, such as mas- 
sages, can be performed in specific wellness centers, wellness, and cosmetic studios, 
but also in hotels specialized in this field. The main working areas in wellness facili- 
ties are the treatment rooms and, depending on the range of services, other addi- 
tional areas for specific therapeutic services. In addition, there are reception or 
registration areas for administrative purposes and, in some facilities, also wait- 
ing rooms. 

Besides the customer, or patient, the therapeutic staff, such as masseurs, physio- 
therapists, or sports therapists, are among the most important people of wellness 
facilities. The list of employees is completed by administrative staff. The number of 
employees depends on the size of the facility. In small wellness and cosmetic stu- 
dios, there are often less than 10 people working there. 


6.7.1.6 Sports Centers and Leisure Parks 


Tertiary prevention may also coincide with rehabilitation. Sometimes, fitness activi- 
ties can be performed not only in certified rehabilitation facilities but also in regular 
sports studios and sports parks. Furthermore, activities for primary prevention may 
be carried out in sports facilities. 

Conventional fitness studios consist of various functional areas. The cardiovas- 
cular area is particularly suitable for improving general fitness and thus preventing 
diseases promoted by a lack of physical activity, such as high blood pressure and 
diabetes. Functional fitness areas with, for example, medicine balls and kettle bells 
as well as free weight areas are used for strengthening. Targeted strengthening of 
the shoulder, back, and neck muscles, for example, can reduce the risk of musculo- 
skeletal disorders of the shoulder and back. 

Customers, or members of a sports center, are one of the most important groups 
of people at sports centers and leisure parks. In addition, there are various service 
employees who are responsible for advising customers on site, assisting members at 
the reception desk, and offering sales services. Various specialized (fitness) trainers 
are responsible for training support and advice. The number of employees depends 
to a great extent on the size of a facility. 
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6.7.2 Technological Perspective 


It is already clear from the basic characteristics described above that there are con- 
siderable differences in the functions to be performed depending on the facility or 
setting. In therapeutic practices and rehabilitation facilities, as in doctors’ practices 
and hospitals, the focus is on the medical or therapeutic treatment of people. The 
function of pharmacies, on the other hand, is to supply people with medicines and 
medical aids. For this purpose, it is necessary to produce, store, and test drugs, as 
well as to dispense these drugs to the patients and inform them about the intake, 
storage, and risks of a drug (advice). 

Consequently, these diverse information processing functions also result in differ- 
ent requirements with regard to the application components that are usually used. 
While application components for prescription and medication management as well 
as specific pharmacy resource planning systems are used in a pharmacy, therapeutic 
practices such as medical practices have patient administration systems for admitting 
and registering patients, MDMS for documenting the therapeutic measures performed, 
and patient administration systems for billing purposes. Even if wellness facilities and 
sports facilities do not focus on a person as a patient, they nevertheless also have appli- 
cation components for scheduling, documenting the services performed, and billing. 


6.7.3 Management Perspective 


Due to the considerable differences in the functions to be performed in the various 
facilities or settings, the way in which management of information systems is orga- 
nized also differs. The more complex the functions are, and the more persons are 
involved, the more management of information systems will be organized in a dedi- 
cated way as in hospitals. In the case of smaller settings and/or limited information 
processing functions, management of information systems might be assigned as an 
additional task to the management in these settings. As in medical offices, these 
persons might be supported by consulting companies, which may also deliver and 
maintain hardware and application software products for application components. 


6.8 Information Systems in Personal Environments 


6.8.1 Characteristics of Personal Environments as Health 
care Settings 


Probably, the most important personal environment for persons are their homes. As 
personal environments, we may also regard workplaces and transport vehicles such 
as cars. As mentioned in Chap. 1, we primarily associate personal environments 
with our regular daily lives. Personal environments, however, may also be related to 
health care. Thus, besides supporting primary prevention and wellness for healthy 
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people, personal environments may also support diagnostic and therapeutic activi- 
ties, rehabilitation, or secondary and tertiary prevention (i.e., to reduce or soften the 
impact of a disease that has already occurred). Health care activities in our personal 
environments are often denoted with terms starting with “tele” or “home,” for exam- 
ple, telecare, telemedicine, telerehabilitation, or home care. 


6.8.2 Technological Perspective 


In the case of tele-activities supporting diagnostics or rehabilitation, these activities 
are often assigned to health care facilities such as hospitals, medical offices, or 
ambulatory nursing organizations. In this case, the functions and application sys- 
tems can be regarded as part of the information systems of these settings. However, 
the information processing activities of these settings do not end within the walls of 
these settings but take place in a personal environment. Therefore, technical com- 
plexity is higher and efforts with regard to data privacy and security are more 
demanding, as informational self-determination is a very sensitive matter. 

In the case of wellness and of primary prevention, the situation is different. Here, 
persons install application systems as introduced in Chap. 3 on their own and use 
these in their personal environments. 


6.8.3 Management Perspective 


In the case of activities which can be assigned to health care settings such as hospi- 
tals, medical offices, or ambulatory nursing organizations, management of informa- 
tion systems is primarily done by these settings. In other activities, for example 
those related to wellness or primary prevention, the persons themselves are respon- 
sible. We would hardly call this management of information systems although it 
would technically be correct. 


6.9 Information Systems in States and Regions 


6.9.1 Characteristics of States and Regions as Health 
care Settings 


In the Universal Declaration of Human Rights of 1948, the right to health is found 
as part of the right of all people to an adequate standard of living. In the International 
Covenant on Economic, Social and Cultural Rights (ICESCR) of the United Nations, 
as well as in other UN human rights treaties, the states commit themselves to ensur- 
ing adequate, non-discriminatory health care. 
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Usually, the government health ministries of the states are responsible for health 
care. Depending on the constitution and size of the states, there are both centralized 
and federal structures. But in most cases, parts of the overall responsibility are del- 
egated to subordinate structures such as federal states, provinces, regions, and 
municipal units. 

Even if the responsibility always remains with the (central) government in the 
end, health care institutions are organized very differently in the individual coun- 
tries. In the United Kingdom, for example, the vast majority of health care facilities 
are part of the state-run National Health Service. In Germany, facilities can be pri- 
vately owned or publicly owned, such as by cities and countries, but they are always 
subject to state supervision. The financing of the health care systems also differs. 
There are state-financed health care systems, systems of almost nationwide compul- 
sory insurance for all citizens that bear the costs of care, or systems where citizens 
must bear the costs themselves. However, the differences can be quite fluid. 

The network of health care in a state or region consists, as already mentioned in 
Sect. 2.6, not only of hospitals and medical offices but also of responsible govern- 
ment agencies and insurance companies, among other things. The global pandemic 
that broke out at the end of 2019 in particular highlights the importance of municipal 
health departments, national disease control authorities (e.g., the Robert Koch 
Institute in Germany), and international institutions (e.g., the European Centre for 
Disease Prevention and Control (ECDS) and the World Health Organization (WHO)). 
However, it also highlights the importance of networking among these agencies. 


6.9.2 Technological Perspective 


We already know from Sect. 2.6 that every state and region in which there is a net- 
work of health care facilities already has, by definition, a transinstitutional health 
information system (tHIS). However, such tHIS are supported by computers to quite 
different degrees depending on the country. Networking between actors requires 
communication and interoperability of the systems involved, just as it does within 
institutions. Very often—even in rich industrialized countries—this communication 
takes place by telephone or postal communication or even by fax. 

The tHIS of states or regions are composed of the institutional information sys- 
tems of the institutions participating in the network. These information systems thus 
incorporate the entire range of application systems described in Sect. 3.4 into the 
tHIS. In order for the institutional information systems to be interoperable with each 
other, they must each have interoperable application systems through which they 
can communicate with the other institutional information systems and thus work 
together. All aspects of interoperability and integration discussed in Sects. 3.7 
through 3.10 play a role in this process, and use of the interoperability standards 
discussed in Sect. 3.7.2 is essential. For example, in Austria, and increasingly in 
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Germany, Integrating the Health care Enterprise (IHE) profiles and especially XDS 
are used for this purpose (Sects. 3.7.2.5 and 3.7.2.6). However, FHIR is becoming 
increasingly important. 

Especially for government agencies and ministries of health, other application 
systems are required in addition to those explained in Sect. 3.4. The WHO describes 
25 types of such application systems in its WHO Classification of Digital Health 
Interventions [2]. However, at this point, the WHO’s terminology does not match 
the terminology in our textbook, so the application systems at WHO are usually 
referred to as information systems. Examples of such types of application systems 
are “community-based information systems” (WHO category F) and “public health 
and disease surveillance system” (WHO category V). The “district health informa- 
tion systems” frequently mentioned in the literature must also be understood as 
application systems that must work together with the other application systems of 
the tHIS via interfaces. 

It makes sense if, in a national health care system and also at the international 
level such as the European Union, a computer-supported infrastructure is available 
at the physical (Sect. 3.10.2) and logical level of the tHIS through which the institu- 
tional information systems can communicate with each other in a standardized man- 
ner. In Germany, for example, this infrastructure is known as the telematics 
infrastructure. 

Worldwide, tHIS are developed very differently at the country level. The level of 
development—sometimes called digital maturity—cannot be determined solely by 
the availability of modern IT. What matters most is whether this technology actually 
brings benefits to health care. A study conducted in 2020 therefore analyzed in vari- 
ous countries whether patients, their caregivers, and medical staff in hospitals or 
other facilities can read and enter the data required for health care. Even rich indus- 
trialized countries performed very poorly [3]. 


6.9.3 Management Perspective 


Responsibility for tHIS at the state or regional level falls to the relevant government 
agencies. These are usually the ministries of health. The framework for tHIS devel- 
opment and responsibilities are defined by law. 

Sometimes, as in Estonia, for example, there is a state chief information officer 
(CIO) who is also responsible for the nationwide tHIS of the health care system. In 
Estonia, this CIO is responsible for the national infrastructure and the use of com- 
munication standards. In other countries, like Finland, for example, responsibility 
for the national tHIS is decentralized and regional structures, for example, prov- 
inces or federal states have responsibility. In Germany, there is a company con- 
trolled by the Federal Ministry of Health, GEMATIK, which is responsible for 
setting up and operating the telematics infrastructure in the country. 
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6.10 Life Situations and Their Consequences 
for Orchestrating Services in Transinstitutional Health 
Information Systems 


In Sect. 1.2, we already saw that people in different life situations are concerned 
about and have to deal with their health. These life situations are closely linked to 
the settings we discussed in the previous sections of Chap. 6. For example, preven- 
tion and wellness are closely linked to the different settings we discussed in Sect. 
6.7 but also to personal environments (Sect. 6.8). Medical emergencies and acute 
illness are taken care of by both hospitals (Sect. 6.2) and medical offices in ambula- 
tory care settings (Sect. 6.4). These settings are also there for the treatment of 
chronic illnesses, but it is precisely in this life situation that the personal environ- 
ment and one’s own home also become therapeutic spaces where, for example, the 
attending physician comes for a home visit and patients acquire knowledge about 
their illness, seek advice via the internet, or plan necessary visits to the doctor and 
specialists (Sect. 3.3.1). Care of the elderly or people with chronic diseases takes 
place both in the nursing home (Sect. 6.3) and in the personal environment, if neces- 
sary with the support of an ambulatory nursing organization (Sect. 6.5). Rehabilitation 
facilities prepare patients for a more “normal” life after emergencies and acute ill- 
nesses but also when chronic illnesses improve. 

This summary shows us clearly that people need very different health care ser- 
vices from different health care settings in different places during their lives. We 
introduced the notion of tHIS in Sect. 2.6, which summarizes the information pro- 
cessing in and between all these health care settings. 

Ultimately, the challenge remains for each person to arrange for themselves to 
find the services they need in the tHIS and to ensure that the services fit together and 
are appropriate for treating their condition. Many are grateful when relatives and 
friends help with the search. GPs can also help to a limited extent. 

In the context of service-oriented architectures (SOAs, Sect. 3.9.4), we are famil- 
iar with the need to compile required services when taking a technical view of 
health information systems. We refer to this as the orchestration of services. We can 
also apply this term to the challenge of citizens to find suitable medical services and 
combine them appropriately. 

Given the complexity of medical services and the medical expertise required to 
orchestrate them, family doctors and hospitals, as already mentioned, take on part of 
the orchestration and organize, for example, the necessary visit to a specialist. We 
refer to this as provider-induced orchestration. But even with such support, patients 
will still need to independently seek appropriate transportation, i.e., other, non- 
medical services. And often, referrals to specialists will only specify the type of spe- 
cialist; patients will have to find the exact person or facility themselves. So the patient 
is left with plenty of complex tasks, which we call patient-induced orchestration. 

In this situation, it is very helpful if the information about offered medical as well 
as non-medical services is available for the citizens. But in the enormous complex- 
ity of transinstitutional health information systems and the abundance of 
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corresponding information, not only elderly people are quickly overwhelmed with 
this patient-induced orchestration. The question arises to what extent information 
technology can also help to find the services needed in a particular health situation 
and ensure that they fit together. For example, it must be ensured that that specialists 
are selected only in such a way that they can be reached from patients’ homes by 
public transport during their consultation hours. Although there is promising 
research on this customer-induced orchestration, much remains to be done. 


6.11 Example 


To support medical research and care, the German Medical Informatics Initiative 
(MI-I) was launched. Four consortia of university medical centers are establishing 
the so-called data integration centers (DICs) for the individual hospitals. These 
DICs are facilities that extract data from the electronic patient records of the respec- 
tive hospitals to make them available for research projects. Note that in each hospi- 
tal, the data from the electronic patient records is scattered around the various 
application systems of this hospital. The consortium SMITH (Smart Medical 
Information Technology for Health care) decided to apply IHE to share data between 
the hospitals and the DICs as well as between the DICs of the different hospitals. 
For details, see [4]. 

Figure 6.4 shows the high-level functions to be performed and the entity types 
involved in a 3LGM? model. The dotted lines indicate that there are still refinements 
to the corresponding tasks and entity types. Patient data (“EMR Data in UH 
Sources”) is taken from the electronic patient records of hospitals (“University 
Hospital (UH)”) and inserted into a separate storage area. There, the data are pre- 
pared and, in particular, semantically “nourished,” i.e., enriched. Also, certain rules 
and methods for processing the data are managed in this “Health Data Storage.” 
When the patients to whom these data belong have given their consent, the data are 
pseudonymized by a trustee unit and made available to research projects by the 
“Transfer Management.” 

At each DIC’s site, application systems are needed to support the local DIC, i.e., 
supporting the execution of functions as well as storing and communicating the 
entity types. Data and knowledge sharing between sites and between patient care 
and research projects (Research & Development Factory) have to be enabled. 
Communication is standards-based, especially using IHE profiles, CDA, FHIR, and 
SNOMED to ensure syntactic, semantic, and process interoperability. 

The architecture of the local information system and their communication links 
at each site follows the DIC reference architecture as outlined in the 3LGM? model 
in Fig. 6.5. Using IHE profiles, the local sub-information systems of the entire tHIS 
of the SMITH network (SMItHIS) are integrated. While applying the DIC reference 
architecture locally, the reference architecture allows for local peculiarities. 

As mentioned before, the DICs have to ingest data from various data sources, 
i.e., different application systems of the local hospital information 
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Data Analytic Services 
(research) 


local DIC information system 


IHE XDS Affinity Domain DIC 


Interface-type A: communication is established through an IHE integration profile, e.g. XDS, PIX, PDQ. 


for this communication is available or used 


Interface-type C: proprietary communication, e.g. ETL 


<p R> Interface-type B: communication is established through an existing communication standard, e.g. HL7v2, FHIR, DICOM. But no IHE integration profile 


Application System provided by industry partner S already existing Application System (various vendors) 


Appl. Sys.) Application System to be developed by SMITH S already existing Application System or provided by industry partners 


Fig. 6.5 SMITH-DIC Reference Architecture at the logical tool layer 


systems. Communication between application systems is classified into three cate- 
gories, A, B, and C, according to their interface type (“if-type”) (see legend in 
Fig. 6.5). Sources of Type A are designed using IHE profiles. There are application 
systems that can serve HL7 and DICOM standards but do not fully implement IHE 
profile. They are referred to here as Type B sources. Type C sources are proprietary, 
such as data provided by comma-separated value (CSV) files. 

The “Data Integration Engine” executes data transformation and load processes 
from sources into the health data storage (HDS). The HDS contains both a compo- 
nent for storing HL7 FHIR resources (Health Data Repository) and an IHE XDS 
document repository comprising clinical data in HL7 CDA documents. Using the 
interface-type scheme (A, B, and C), data are shared beyond department borders. 
Precise explanations of other details can be found in [4]. 


6.12 Exercises 


6.12.1 Research Architecture 


A clinical researcher at Ploetzberg Hospital has won a grant to set up a register for 
patients who have received a knee endoprosthesis. Disease registers are research 
databases for collecting data about a specific disease, aiming for full coverage of the 
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respective patient collective. The aim of a knee endoprosthesis registry is to collect 
longitudinal data to find out which type of endoprosthesis works best over time. The 
researcher wants to integrate data from patient-reported outcome questionnaires, 
findings from inpatient or outpatient visits at the hospital, and results from labora- 
tory examinations. Which entity types need to be integrated and from which appli- 
cation components do they come? Devise a plan how you would set up a sustainable 
research architecture, i.e., an architecture that also could be used in other research 
settings and for different disease or research entities, considering Sect. 6.6. 


6.12.2 Medical Admission 


In which of the health care settings above will the function medical admission need 
to be supported? 
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Solutions to Exercises 


Chapter 1: Introduction 


Exercise 1.5.1 Life Situations 

My father was admitted to the hospital after suddenly showing symptoms of numb- 
ness in the left arm, confusion, and trouble seeing while at home. We called the 
ambulance, and after a short examination, the ambulance team took him to the near- 
est hospital for further diagnosis and treatment. This situation corresponds to an 
emergency life situation. I participated in this situation as a close relative. My urgent 
requirements were to know which hospital my father was taken to and to obtain 
more information on the suspected diagnosis (here: stroke) and the next steps of 
diagnosis and therapy. 


Exercise 1.5.2 Requirements of Various Stakeholders 

While a patient is being treated for an acute disease, the requirements of the treating 
physicians and nurses as well as of the patient and relatives may differ. For example, 
patient and relatives want to be kept informed of ongoing diagnostic outcomes (e.g., 
lab values) as soon as possible. However, physicians and nurses may want to discuss 
the findings with the patient in person to avoid causing unnecessary confusion and 
stress in the patient. Therefore, the health information system must be able to pro- 
vide detailed information to physicians and nurses, but it must be able to only pres- 
ent confirmed information to the patient (e.g., via a patient portal). 


Chapter 2: Basic Concepts and Terms 


Exercise 2.16.1 Data, Information, and Knowledge 

“160,” “100,” “hypertension,” and “blood pressure” represent data that cannot be 
interpreted without knowledge about the context. The information is that Mr. Russo 
has been diagnosed with hypertension and that his last blood pressure is 
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160/100 mmHg. The medical knowledge embedded in this example is that a blood 
pressure of 160/100 mmHg indicates hypertension that should be treated. 


Exercise 2.16.2 Systems and Subsystems 

The nervous system comprises two main categories of cells: neurons and glial cells. 
Neurons communicate with each other via synapses and thus form their own sub- 
system. Glial cells form another subsystem that provides support and nutrition to 
the neurons. 

The hospital can be understood as a system comprising at least two subsystems: 
the subsystem where clinical care takes place and the subsystem where manage- 
ment takes place. The clinical subsystem can again be split into several subsystems, 
such as inpatient area, outpatient area, and specialized diagnostic or therapeutic 
areas. The inpatient area itself can be divided into various subsystems, each repre- 
sented by one ward. The way I define the subsystems of a hospital depends on the 
questions or intentions I have. 


Exercise 2.16.3 Information Logistics 

The physician wants to have access to the right information (the most recent blood 
pressure) at the right time (when talking to Mr. Russo) at the right place (at the 
patient’s bedside) in the right form (hopefully the blood pressure is provided in an 
easy-to-grasp, visual way) so that he can make the right decision (here: to decide on 
the level of a certain medication). If the information system does not support this, 
the physician may obtain an incorrect or outdated blood pressure measurement, or 
he may misinterpret it, thereby coming to a decision that is suboptimal for the 
patient. 


Exercise 2.16.4 3LGM’ Metamodel 

Administrative admission is an enterprise function that is supported by the patient 
administration system. One entity type that is used and updated by this function is 
“patient.” The paper-based patient data privacy form system is an example of a non- 
computer-based application component. The virtualized server farm is an example 
of a physical tool. The inter-layer relationships of this example show which func- 
tions are supported by which application system and which physical data processing 
system the application systems are installed on. 


Exercise 2.16.5 Interpreting 3LGM? Models 

(a) The function “patient admission” is decomposed into five subfunctions— 
patient admission is only complete if all the subfunctions are completed. The 
entity type “patient” is decomposed into four entity types—data regarding that 
entity type are only complete if data about all sub-entity types is complete. 
There are no examples of specialization at the domain layer of Fig. 2.11. 

(b) The function “patient identification” updates the entity type “patient.” The 
function “medical admission” uses the entity type “patient.” This indicates that 
identifying patient data are updated or created during patient admission and 
then used for medical admission. 
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(c) The entity type “privacy statement” could be added at the domain layer. It 
would be updated by the function “obtaining consent for processing of 
patient data.” 

(d) Patient admission is decomposed into five subfunctions with each being linked 
to an application component by which it is supported. Therefore, it could lead 
to an ambiguous model if the superordinated function was linked with another 
application component. The corresponding modeling rule says that only the leaf 
functions in a function hierarchy should be linked to application components. 

(e) The function “obtaining patient consent for the processing of data” is supported 
by the paper-based patient data privacy form system. For this, a paper record 
cabinet, a scanner, and a clerk handling these tools are the physical data pro- 
cessing systems needed for the function. 


Chapter 3: Technological Perspective 


Exercise 3.12.1 Domain Layer: Differences in Hospital Functions 

A typical hospital needs all functions to function as expected. The functions to be 
performed by health care professionals are mostly similar in all health care facili- 
ties, independent of their size. Only some functions may differ. For example, not all 
health care facilities are involved in clinical research, thus their information will not 
need to support the function research and education. 


Exercise 3.12.2 Domain Layer: Different Health care Professional Groups 
and Health care Facilities 

Physicians: Important functions are medical admission, decision-making and 
patient information, planning and organization of patient treatment, order entry, 
execution of diagnostic and therapeutic procedures, coding of diagnoses and proce- 
dures, and medical discharge and medical discharge summary writing. 

Nurses: Important functions are nursing admission, decision-making and patient 
information, planning and organization of patient treatment, order entry, execution 
of nursing procedures, and nursing discharge and nursing discharge summary 
writing. 

Administrative staff: Important functions are patient identification, administra- 
tive admission, and administrative discharge and billing. 


Exercise 3.12.3 Domain Layer: the Patient Entity Type 
The entity type “patient” is updated by the function “patient admission.” All other 
functions that are related to patient care interpret it. 


Exercise 3.12.4 Logical Tool Layer: Communication Server 

Short-term advantages: The communication server can handle the communication 
between all four application systems, including receiving, buffering, transforming, 
and multicasting of messages. It can also be used for monitoring the communication 
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traffic. The communication server thus supports data integration in heterogeneous 
information system architectures. 

Long-term advantages: In the resulting (AC", CP’) architecture, new application 
components can easily be integrated, as only one communication interface to the 
communication server needs to be implemented. 

Standards: For the exchange of administrative data, HL7 V2 or V3 could be used 
as syntactic or semantic standard. For the exchange of clinical data, various com- 
munication standards can be chosen such as HL7 FHIR, DICOM for medical 
images, or HL7 CDA for clinical documents. 


Exercise 3.12.5 Logical Tool Layer: Integration from the User’s Point of View 
Data integration would be considered high when the nurse documents patient 
administrative data only once in the patient administration system and then can use 
this data in the NMDS. 

Semantic integration would be considered high when the nurse documents a 
nursing diagnosis using a standardized terminology (such as NANDA) and when 
this standardized diagnosis is then understood by the NMDS that may, for example, 
suggest a standard nursing care plan for this patient based on this diagnosis. 

User interface integration would be considered high when the user interfaces of 
both application systems look sufficiently similar, which reduces the risk of data 
entry or data interpretation errors. For example, in both application systems, the 
names of the patients are always displayed at the same place, the birthdates are 
presented in standardized form, and colors that are used to highlight important 
information are used in the same way. 

Context integration would be considered high when the user context and the 
patient context is preserved when the nurse shifts from one application system to the 
other. The nurse thus would not have to repeat user login or the selection of the 
patient in the second application system. 

Feature integration would be considered high when only the patient administra- 
tion system offers the needed administrative features (such as documentation of 
patient address). The nurse would be able to call up these features from within 
the NMDS. 

Process integration would be considered high if both application systems work 
together in a highly integrated way so that the process of patient admission and 
nursing care planning from the point of view of the nurse is supported in an effi- 
cient way. 


Exercise 3.12.6 CityCare 

(a) EHR systems as comprehensive application systems combine the functional- 
ities of MDMS, NDMS, and CPOE systems. The EHRS of CityCare could 
therefore be used for medical admission, preparation of an order, or execution 
of diagnostic and therapeutic procedures. However, each of the three health 
care facilities in CityCare has its own MDMS. Therefore, the EHRS is probably 
mainly used for accessing findings from the other health care facilities, for 
example, during medical admission. For the VNA, no suitable function is mod- 
eled at the domain layer. At the domain layer, archiving of patient information 
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(b 


(c 


(d 


(e 


wm 


wm 


wm 


wm 


could be added which is supported by the VNA and, to some extent, also by 
the EHRS. 
The entity type “patient” represents the persons who are the subject of health 
care. Information about a patient includes the PIN and other administrative data 
about the person. Each of the application systems supporting subfunctions of 
patient care and having an own database system stores the entity type “patient,” 
for example, the patient administration system including the MPI, the MDMS, 
the EHRS, and the VNA. 
In Ernst Jokl Hospital, there is a star architecture at the logical tool layer, i.e., a 
communication server is used for the exchange of messages between applica- 
tion systems. The patient administration system of Ernst Jokl Hospital, where 
the PINs of Ernst Jokl Hospital are generated, sends this information in a mes- 
sage to the communication server. The communication server forwards the 
message to the MPI of the health care network. In the central MPI of the tHIS, 
the local patient identification numbers of the different health care facilities are 
linked to the unique transinstitutional patient identification number of CityCare. 
Administrative admission, appointment scheduling, medical admission, order 
entry, patient identification, and preparation of an order are each supported by 
at least three application systems in the scenario. 

Pros (examples): 


e Each of the health care facilities has a functioning information system that is 
independent from changes or system failures in the other health care facilities. 
The different patient administration systems and medical documentation and 
management systems may be better adapted to the local needs and grown 
structures in the single health care facilities than an application system that is 
used by all of them together. 

Cons (examples): 


Three or more different application systems that support the same function 
cause higher costs and higher administrative effort. 
The effort for establishing integration and interoperability are higher in func- 
tional redundant architectures which have a high number of single application 
systems. 

Resolving these redundancies (examples): 


One patient administration system that supports patient identification and 
administrative admission could be used in all health care facilities instead of 
three patient administration system and an MPI. 

The central EHRS could be used as MDMS, NDMS as well as CPOE system 
in each of the facilities and would replace the existing local application 
systems. 


According to the matrix view in Fig. 3.37, the MDMS of Ploetzberg Hospital is 
installed on application server 1 Ernst Jokl Hospital. Thus, if this application 
server | Ernst Jokl Hospital fails, the following functions cannot no longer be 
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(f) 


performed: appointment scheduling, medical admission, order entry, and prepa- 
ration of an order (see matrix view in Fig. 3.35). 

The application systems used in CityCare should be made available by 

server clusters with redundant servers. If one server in a server cluster fails, 
another server can take over its task. Thus, there is no interruption in function 
support. 
Yes, it makes sense to use further integration profiles from IHE. For example, 
IHE XDS could be used. The CityCare network could be established as an affin- 
ity domain with several actors that interact in a standardized way (process interop- 
erability) to share document-level or even large binary patient data, such as 
findings, images, or radiology reports. These documents would be registered cen- 
trally in a document registry and could be retrieved by other systems. Depending 
on how the central EHRS is implemented, it could either take the role of a docu- 
ment registry that forwards the requests to a decentral source, or it could—as in 
our case of a central database—act as a central document provider itself. 


Chapter 4: Management Perspective 


Ex 


ercise 4.9.1 Activities of Managing Information Systems 

Developing a strategic information management plan: strategic planning. 
Initiating projects from the strategic project portfolio: strategic directing. 
Collecting and analyzing data from user surveys on their general health informa- 
tion system’s satisfaction: strategic monitoring. 

Planning a project to select and introduce a new CPOE system: tactical planning. 
Executing work packages within an evaluation project of a CPOE system: tacti- 
cal directing. 

Assessment of user satisfaction with a new intensive care system: tactical 
monitoring. 

Planning of a user service desk for a group of clinical application components: 
operational planning. 

Operation of a service desk for a group of clinical application components: oper- 
ational directing. 

Daily monitoring of network availability and network failures: operational 
monitoring. 


Exercise 4.9.2 Strategic Alignment of Hospital Goals and Information 
Management Goals 


Go 


33 


als: efficient and high-quality information logistics to support patient care. 
Functions: patient administration and all functions related to patient care (Sect. 
2.1). 

Project portfolio and migration plan: 


Year 1: Introduction of a patient administration system. 
Year 2: Introduction of a CIS, an LIS and an RIS. 
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Year 3: Introduction of a DAS and a PACS. 
Year 4: Introduction of an OMS and of a PDMS. 
Year 5: Introduction of a DWS and of a patient portal. 


Please note: This is a simplified solution. Other solutions may be valid, too. In 


case the different application systems are meant to come from different vendors, an 
integration technology such as a communication server needs to be implemented. 


Exercise 4.9.3 Structure of a Strategic Information Management Plan 


Strategic goals of the health care facility (business goals) and of management 
of information systems: are visible in Chaps. 1 and 2 of Ploetzberg 
Hospital’s plan. 

Description of the current state of the information system: are visible in Chap. 3 
of Ploetzberg Hospital’s plan. 

Assessment of the current state of the information system: are visible in Chap. 4 
of Ploetzberg Hospital’s plan. 

Future state of the information system: are visible in Chap. 5 of Ploetzberg 
Hospital’s plan. 

Migration path from the current to the planned state: are visible in Chap. 6 of 
Ploetzberg Hospital’s plan. 


Exercise 4.9.4 An Information-Processing Monitoring Report 


KPI Ploetzberg Hospital | My hospital 
Number of HIS staff 46 89 
Number of HIS users 4800 9000 
Number of workstations 1350 6200 
Number of mobile IT tools 2500 | 2000 
HIS user per mobile IT tool 1.9 4.5 
Number of IT problem tickets 15,500 36,250 
Percentage of solved IT problem tickets 96% 92% 
Availability of the overall HIS systems 98.5% 96% 
Number of finalized strategic IT projects 13 10 
Percentage of successful IT projects 716% | 86% 


Exercise 4.9.5 Relevant Key Performance Indicators 
Several solutions are possible here. One possible solution: 


1. 


2. 


HIS user per mobile IT tool: Efficient information logistics everywhere (e.g., at 
the patient’s bedside) requires enough mobile IT tools. 

Number of application systems: I would strive for an integrated information sys- 
tem and reduce the number of application systems in the long run in order to 
reduce integration problems. 


. HIS budget in relation to the overall hospital budget: Sufficient funding is the 


precondition for high-quality and well-integrated information system and the 
necessary competent IT staff. 
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Exercise 4.9.6 Organizing User Feedback 

User groups: physicians, nurses, technical staff (e.g., lab, radiology), and manage- 
ment staff—these groups are typically large health information systems user groups. 
I would also organize regular survey of CIS key users, as they are experts in judging 
the quality of the information systems. 

Organization of user feedback: (1) Health information system users are ran- 
domly invited to an automatic short and standardized survey that is displayed during 
CIS login. (2) Every half year, I would organize sounding boards (a structured 
approach to obtain active feedback from stakeholders) with key users and with rep- 
resentatives from the larger user groups to discuss recent challenges with the CIS 
and opportunities for improvements. 


Exercise 4.9.7 Information Systems Managers as Architects 

Health information managers can indeed be compared with architects. Health infor- 
mation managers design information systems that are used by many different user 
groups. Health information managers regularly monitor the quality of information 
systems to obtain feedback and to improve the information system. Health informa- 
tion managers understand that information systems support many different func- 
tions for many different user groups within health care facilities. Health information 
managers make sure that the application systems are user-friendly and support 
working processes in an efficient way. Health information managers understand that 
an information system serves the overall goal of a health care facility and ultimately 
serves the need of the patients. 


Chapter 5: Quality of Health Information Systems 


Exercise 5.6.1 Quality of Integration 

1. A physician enters a medical diagnosis for a patient first in the MDMS and later, 
when ordering an X-ray, again in the CPOE system. — No data integration, 
resulting in reentering of data, which is time-consuming and may lead to errors 
and inconsistencies in the data, which has the potential for patient harm. 

2. The position of the patient’s name and the formatting of the patient’s birthdate 
vary between the MDMS and the CPOE system. — No user interface integration, 
resulting in increased time effort when using various application components, 
increased time needed for user training, and increased risk in overlooking or 
misinterpreting important patient information, which has the potential for 
patient harm. 

3. When physicians shift from the MDMS to the CPOE system, they have to log in 
again and again search for the correct patient. > No context integration, lead- 
ing to an increase in time needed to shift between application systems and an 
increased risk for selecting the wrong patient in the second application systems, 
which has the potential for patient harm. 
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4. The CPOE system and the RIS use slightly different catalogs of available radiol- 
ogy examinations. > No semantic integration, making the exchange and reuse of 
patient information in both application systems challenging. 

5. When physicians write the discharge letter for a patient in the MDMS, they also 
have to code the discharge diagnosis of a patient. For this coding, they have to 
use a feature that is only available in the patient administration system, so they 
have to shift to this application system. —> No feature integration, leading to 
increased time needed to shift to the patient administration system. 

6. While being at the patient’s bedside during their ward rounds, physicians have 
to use several application components at the same time, such as MDMS for 
retrieving recent findings, the CPOE system for ordering, and the PACS for 
retrieving images. > No process integration; a process should be organized in a 
way that frequent change of application systems is avoided if possible. 


Exercise 5.6.2 Data Collection in Evaluation Studies 
Study “Unintended Effects of a Computerized Physician Order Entry Nearly Hard- 
stop Alert”: The effectiveness of a nearly “hard-stop” alert was evaluated in a field 
study. The data was collected via analysis of the prescriptions in the CPOE systems. 
The overall data collection method is thus a quantitative observation of available data. 
Study “Clinical Decision Support for Worker Health: A Five-Site Qualitative 
Needs Assessment in Primary Care Setting”: data were collected via interviews and 
qualitative observations. 


Exercise 5.6.3 Study Design in Evaluation Studies 
Study “Unintended Effects of a Computerized Physician Order Entry Nearly Hard- 
Stop Alert”: This quantitative and explanatory field study was organized as an RCT: 
1981 clinicians were randomly assigned to either the intervention group or the con- 
trol group. RCTs are considered the gold standard, as they provide a rigorous tool 
to assess cause-effect relationships between intervention and outcome. 

Study “Clinical Decision Support for Worker Health: A Five-Site Qualitative 
Needs Assessment in Primary Care Setting”: This is a qualitative, explorative 
field study. 


Chapter 6: Information Systems for Specific Health Care 
and Research Settings 


Exercise 6.12.1 Research Architecture 
The following entity types have to be integrated: patient, person, diagnosis, finding, 
health record, medical procedure, patient record, self-gathered symptoms, material, 
medical device, classification, nomenclature. 

Application components to be integrated depend on local settings and implemen- 
tation but will likely include: patient administration system, MDMS, LIS, OMS, 
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PDMS, and self-diagnosis systems (e.g., an app for collecting patient-reported out- 
come data) or patient portals. 

A research architecture for setting up multiple registries might include a DWS 
for research that is fed via ETL processes from the above-mentioned application 
components and can be tapped for data in different use cases or research scenarios. 
Finally, an open platform architecture would enable reuse of patient data in various 
research contexts. 


Exercise 6.12.2 Medical Admission 

The function “medical admission” is relevant in several health care and research 
settings. It comprises the provision of forms for documenting medical history, docu- 
menting diagnoses, and scanning documents from referring physician and other 
sources of information about the medical history. It is obvious that this function 
needs to be supported in hospitals, nursing homes, ambulatory nursing organiza- 
tions, and medical offices. Yet it is often also necessary in research settings, for 
example, when a person is recruited for a clinical trial and their data are entered into 
an EDC system. Furthermore, therapeutic offices need this function for documenta- 
tion purposes, as do rehabilitation facilities and—to a limited extent—wellness or 
sports facilities. For personal environments, medical admission also plays a role, 
especially in telecare situations or when prevention measures are conducted, 
respectively. 


Glossary’ 


3LGM? Metamodel for modeling — information systems on three layers: > 
domain layer, > logical tool layer, and > physical tool layer (Sect. 2.14). 

AC! architecture See —> monolithic architecture (Sect. 3.6.2). 

AC" architecture See —> modular architecture (Sect. 3.6.2). 

Activity Instantiation of a > function. In contrast to functions, activities have a 
definite beginning and end (Sect. 2.8). 

ADT HL7 message type for —> messages related to admission, discharge, and 
transfer of a patient (Sect. 3.7.2.1). 

All-in-one architecture A — monolithic (AC', V!) architecture or an (AC", V') 
architecture in which the > health care facility selected only > application soft- 
ware products from exactly one vendor to support as many — information pro- 
cessing functions as necessary (Sect. 3.6.3). 

Annual project portfolio Describes the > projects to be initiated in the next year. 
It is derived from the — strategic project portfolio (Sect. 4.3.1.3). 

Application component Set of implemented rules which control data processing 
of certain —> physical data processing systems. An application component sup- 
ports certain > information processing functions of a > health care setting or 
communication between application components. Application components can 
either be computer-based application components (— application system) or > 
non-computer-based application components (paper-based application compo- 
nent) (Sect. 2.9). 

Application software product Acquired or self-developed piece of software that 
can be installed on a > computer system (Sect. 2.9). 

Application system Installation of a certain > application software product on a 
certain computer system; specialization of —> application component (Sect. 2.9). 


'This glossary lists all relevant terms introduced and used in this book. In the main text, these terms 
are written in italics when first introduced and when defined. Application systems and functions 
are always written in italics in the main text. Functions are not included in the glossary. 
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Archetype Basic building blocks representing clinical concepts. Can be reused as 
semantic building blocks for the standardized representation of clinical > infor- 
mation in > electronic health records (Sect. 3.7.2.8). 

Architectural style Characterizes the > architecture of the computer-based part 
of — health information systems. On the —> logical tool layer, we can describe 
architectural styles by the number of databases (> DB!, > DB”), number of > 
application systems (> AC!, > AC”), number of > application software prod- 
ucts and vendors (> V!, > V”), and the patterns of > communication links (> 
CP!, > CP") between the application systems (Sect. 3.6). 

Architecture of an information system Fundamental organization of the > 
information system, represented by its => components, their relationships to 
each other and to the environment, and by the principles guiding its design 
and evolution. Architectures can be summarized into > architectural styles 
(Sect. 2.11). 

Asynchronous communication Communication between — application systems 
that is not simultaneous. Thus, the > application system sending a > message 
will continue its tasks without interruption even when awaiting a response > 
message from the communication partner (Sect. 3.9.2). 

Benchmarking Method of strategic > monitoring of > information systems in 
which organizations evaluate various aspects of their performance and compare 
it to a given standard or to the best organizations (“best practice”). Typically, 
benchmarking uses quantitative criteria (—> key performance indicators) for 
comparing situations (Sect. 4.3.2.2). 

Best-of-breed architecture An (AC", V”) architecture where the different > appli- 
cation systems are based on —> software from different vendors, pointing to the 
fact that the — health care facility combines the “best” application software 
products from different vendors (Sect. 3.6.3). 

Business goals The strategic, long-term goals of a — health care facility (Sect. 
4.3.1.1). 

Business process Sequence of — activities together with the conditions under 
which they are performed (Sect. 2.8). 

Case identification number (CIN) Unique identification of a patient case (Sect. 
Sdede 1.2): 

Central architecture — Architecture of an information system where all > appli- 
cation systems store their patient-related — data in only one database system. 
Synonym: DB! architecture (Sect. 3.6.1.1). 

Certification Confirming that an object or organization has certain characteristics. 
Certification of — health information systems in general describes a process 
where an accredited body confirms that the information system of a > health 
care facility fulfills certain —> quality characteristics that have been predefined 
by an external organization (Sects. 5.2.3 and 5.5.3). 

Chief information officer (CIO) Role that is responsible for the — strategic, > 
tactical, and > operational management and the related budget of the — infor- 
mation system. The CIO usually has authority over all employees concerned 
with > management of the information system (Sect. 4.6.2). 
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Clinical information system (CIS) — Application system that integrates a > 
medical documentation and management system, a > nursing management and 
documentation system or a > CPOE system as modules. A CIS is also often 
called — electronic health record system (EHRS) (Sect. 3.4.15). 

Communication interface Used by > application systems for sending or receiv- 
ing —> messages over > communication links (Sect. 2.14.2.2). 

Communication link Communicates messages. Connects a > communication 
interface of one — application system with a > communication interface of 
another —> application system (Sect. 2.14.2.2). 

Communication server — Application system used for the asynchronous receiv- 
ing, buffering, transforming, and sending of —> messages (Sect. 3.9.2). 

Components of an information system — Enterprise functions, > business pro- 
cesses, > application components, and > physical data processing systems. If 
a system consists of both human and technical components, it can be called a > 
socio-technical system (Chap. 2). 

Computer-based application component See — application system (Sect. 2.9). 

Computer-based sub-information system — Sub-information system that uses 
computer-based data processing and communication tools (Sect. 2.5). 

Computer-based health information system — Health information system that 
uses computer-based data processing and communication tools (Sect. 2.6). 

Computer system A computer-based — physical data processing tool, for exam- 
ple, a terminal, server, or personal computer (PC). Computer systems can be 
physically connected, leading to physical networks (Sect. 2.9). 

Computerized provider order entry system (CPOE) — Application system sup- 
porting the — functions related to order entry, such as formulation of an order, 
appointment scheduling, printing of labels, and the communication of the order 
to the service unit (Sect. 3.4.4). 

Context integration Condition of an — information system in which the con- 
text (e.g., user identification and patient selection) is preserved when the user 
changes the — application system (Sect. 3.8.4). 

CP! architecture See —> star architecture (Sect. 3.6.4). 

CP" architecture See — spaghetti architecture (Sect. 3.6.4). 

Data Characters, discrete numbers, or continuous signals to be processed in > 
information systems (Sect. 2.2). 

Data consistency Situation where copies of > data representing the same — entity 
are identical. Consistency of data is one element of > data integrity within > 
health information systems (Sect. 3.5). 

Data integration Condition of an > information system where — data that have 
been recorded and stored once in one — application component is made avail- 
able in a coherent and uniform way wherever they are needed, i.e., in other appli- 
cation components, without having to be reentered. Data integration helps to 
increase > data consistency (Sect. 3.8.1). 

Data integrity Situation where > data in > information systems are correct. 
Comprises — object identity, > referential integrity, and — data consistency 
(Sect. 3.5). 
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Data warehouse system (DWS) — Application system supporting — functions 
related to the collection, analysis, and presentation of up-to-date —> information 
extracted from other > application systems to support hospital management or 
clinical research (Sect. 3.4.11). 

DB! architecture See — central architecture (Sect. 3.6.1.1). 

DB" architecture See — distributed architecture (Sect. 3.6.1.2). 

Directing Task of — strategic management of information system that comprises 
the transformation of a > strategic information management plan into action, 
typically by initiation of — projects (Sect. 4.3.3). 

Distributed architecture — Architecture of an information system where the > 
information system comprises several — application components that each store 
— data on certain > entity types persistently in their own database. Synonym: 
DB? style (Sect. 3.6.1.2). 

Document archiving system (DAS) — Application system supporting long-term 
archiving of paper-based and digital documents. Can be realized by —> vendor- 
neutral archives (VNAs) (Sect. 3.4.12). 

Domain layer Part of a > 3LGM? model. Describes what kinds of activities in a 
health care setting are enabled by its — information system and what kind of 
— data are stored and processed. Consequently, the domain layer describes > 
information processing functions and — entity types (Sect. 2.14.1). 

Electronic health record (EHR) Collection of a person’s health —> data from dif- 
ferent — health care settings. The EHR is stored by one or more —> application 
systems in a —> transinstitutional health information system (Sect. 2.10). 

Electronic patient record (EPR) Collection of a person’s health > data from one 
certain > health care facility where the person is or has been a patient. The EPR 
is stored by — application systems designated for this purpose by the facility 
(Sect. 2.10). 

Enterprise function In business informatics, enterprise functions mainly empha- 
size the contribution of — activities to > business goals. In contrast, the term 
— information processing function emphasizes the — information processing 
aspects of activities (Sect. 2.8). 

Enterprise resource planning system (ERPS) — Application system support- 
ing — functions related to the management of financial, human, and material 
resources of a > health care facility (Sect. 3.4.10). 

Entity Excerpt of the real or conceivable world (Sect. 2.8). 

Entity type Set of virtual or physical — entities that have certain properties in 
common (e.g., “discharge letter” or “patient”) (Sect. 2.8). 

Evaluation Act of measuring or exploring > components of a > health informa- 
tion system. The result of an evaluation should provide information to support 
decisions concerning the health information system, such as decisions regard- 
ing optimizing, replacing, or further deploying an — application component 
(Sect. 5.4). 

Feature Functionality offered by the — application software product of an > 
application system which directly contributes to the fulfillment of one or more 
— functions (Sect. 2.9). 
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Feature integration Condition of an > information system in which > features 
needed in more than one —> application systems are implemented only once, 
for example, as > services, and can be invoked by other application systems 
(Sect. 3.8.5). 

Function Short for > information processing function (Sect. 2.8). 

Functional leanness Situation where one > function is supported by one and only 
one — application component (Sect. 4.7.4). 

Health care facility Health care institutions such as hospitals, nursing homes, or 
general practitioners (GP); type of > health care setting (Sect. 2.3). 

Health care network — Health care setting consisting of different actors enabling 
a patient-oriented process, encompassing prevention, diagnosis, and therapy 
spreading over > health care facilities’ boundaries and integrating the citizens’ 
home environment (Sect. 2.6). The —> information system of a health care net- 
work is called a > transinstitutional health information system. 

Health care professional A person working in —> health care settings, such as a 
physician, nurse, midwife, pharmacist, or physiotherapist (Sect. 1.3.2). 

Health care setting Places, social contexts, or facilities related to health care where 
people actively use and shape the environment and thus create or solve problems, 
such as cities, villages, private homes, medical offices, hospitals, health care 
regions, — health care facilities, and — health care networks (Sect. 2.3). 

Health information system — Information system of a > health-related setting. 
Socio-technical subsystem of a — health-related setting which comprises all 
— data, — information, and — knowledge processing as well as the associated 
human or technical actors in their respective data, information, and knowledge 
processing roles (Sect. 2.6). 

Heterogeneous architecture — Architecture of an information system where > 
application software products come from several vendors. Synonym: V" archi- 
tecture (Sect. 3.6.3). 

Homogeneous architecture — Architecture of an information system where > 
application software products come from only one vendor. Synonym: V! archi- 
tecture (Sect. 3.6.3). 

Hospital information system — Information system of a hospital (Sect. 2.6). 

Information Context-specific fact about — entities such as events, things, per- 
sons, processes, ideas, or concepts. Information is represented by —> data 
(Sect. 2.2). 

Information and knowledge logistics Making the right —> information and > 
knowledge available at the right time, at the right place, to the right people, and in 
the right form, so that these people can make the right decisions. > Information 
systems support information and knowledge logistics (Sect. 2.7). 

Information management Short for — management of information systems 
(Sect. 2.12). 

Information management board Board to make strategic decisions on the > 
information system. Members of this board are typically representatives from 
the top management and from the main departments of a > health care facility. 
Synonym: IT steering committee (Sect. 4.6.3). 
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Information model Description of entity types and their relationships at a con- 
ceptual level, independent of any specific implementation or > protocols. In 
contrast, a data model is defined at a lower level of abstraction and is intended 
for implementers of databases (see Sect. 3.7.1.3). 

Information processing function (short: function) Directive in a > health care 
setting on how to use > data on > entity types and how to update data on entity 
types. An information processing function has no definitive beginning or end 
(Sect. 2.8). 

Information system — Socio-technical subsystem of a setting which comprises all 
— data, — information, and —> knowledge processing as well as the associated 
human or technical actors in their respective data, information, and knowledge 
processing roles. Information systems support — information and knowledge 
logistics (Sect. 2.5). 

Infrastructure of an information system Set of > components of the > infor- 
mation system and services which are centrally coordinated and provided for 
use throughout the —> health care setting, such as > physical data processing 
systems and — application systems (Sect. 2.11). 

Integration Union of parts making a whole, which—as opposed to its parts—dis- 
plays a new quality. Different types of integration on the > logical tool layer 
are — data integration, > semantic integration, > user interface integration, > 
context integration, > feature integration, and —> process integration. On the > 
physical tool layer, > physical integration is important (Sect. 3.8). 

Integrity See — data integrity (Sect. 3.5). 

Inter-layer relationship Dependencies among —> components of different layers 
in the > 3LGM7. Relationships exist between concepts at the > domain layer 
and the > logical tool layer and between concepts at the logical tool layer and 
the > physical tool layer (Sect. 2.14.4). 

Interoperability Ability of two > application systems to exchange —> information 
with each other and to use the information that has been exchanged. Aspects 
of interoperability comprise — technical interoperability, > syntactic interoper- 
ability, + semantic interoperability, and — process interoperability (Sect. 3.7). 

Interoperability standard Comprises standards for > technical interoperability 
(also called — protocols), => syntactic interoperability (also called communi- 
cation standard or message standards), > semantic interoperability (common 
information models, —> terminology standards), and — process interoperability 
(Sect. 3.7.2). 

IT governance Part of the overall management of a > health care facility. It deals 
with defining the organizational structures for decision-making for > informa- 
tion management in such a way that the management of information systems is 
well integrated with the health care facility’s management and is aligned to its 
strategic goals (— strategic alignment) (Sect. 4.6.1). 

IT risk management Continuously assesses risks and liabilities of the > manage- 
ment of information systems (Sect. 5.2.2). 
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IT service Services provided by > operational information management that are 
designed to help users use — application systems and —> physical data process- 
ing tools in a way that is helpful for their professional work (Sect. 4.5). 

IT service management (ITSM) Activities of — information management that 
serve to provide high-quality — IT services (Sect. 4.5). 

IT strategy See — strategic information management plan (Sect. 4.3.1.2). 

Key performance indicators (KPI) Set of quantitative and well-defined perfor- 
mance measurements that demonstrate how effectively an organization is achiev- 
ing key objectives. Can be used for > benchmarking of — health information 
systems (Sect. 4.3.2.1). 

Knowledge General > information about concepts in a certain (scientific or pro- 
fessional) domain (e.g., knowledge about diseases or therapeutic methods) at a 
certain time (Sect. 2.2). 

Laboratory information system (LIS) — Application system supporting > func- 
tions related to the —> information processing of a laboratory unit of a > health 
care facility (Sect. 3.4.7). 

Life situation Situation in life where > health information systems may play an 
important role. Life situations comprise normal living, emergencies, acute dis- 
eases, chronic diseases, care, and rehabilitation (Sect. 1.2). 

Logical tool See — application component (Sect. 2.14.2). 

Logical tool layer Part of a > 3LGM?. Describes > application systems or, 
in a broader sense, > application components that support information pro- 
cessing functions and their > communication links among each other (Sect. 
2.14.2). 

Management of information systems (short: information manage- 
ment) Planning the > information system and its > architecture, > directing 
its construction and the further development of its architecture and its operation 
on the basis of these plans, and monitoring compliance of its development and 
operation with the plan specifications. Comprises — strategic, > tactical, and > 
operational information management (Sect. 2.12). 

Primary application system — Application system that contains the original > 
data about a given > entity type. These data can only be inserted, deleted, or 
changed in this primary application system (Sect. 3.9.1). 

Master patient index (MPI) — Application component providing a correct > 
patient identification number (PIN) in an institutional > health information sys- 
tem and even in > transinstitutional information systems with several —> patient 
administration systems (Sect. 3.4.1). 

Medical documentation and management system (MDMS) — Application sys- 
tem supporting — functions related to organizing and documenting patients’ 
diagnostics and treatment from a medical point of view (Sect. 3.4.2). 

Message Set of data on > entity types (e.g., administrative data of a given patient) 
that are arranged as a unit in order to be communicated between — application 
systems (Sect. 2.14.2.2). 
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Metadata Data about — data. Metadata provides information about one or more 
aspects of data such as purpose of the data, author and time of creation, used 
standards, or file size (Sect. 2.2). 

Metamodel Modeling framework consisting of syntax, semantics, representations 

of context, and modeling rules. For example: > 3LGM? (Sect. 2.13). 

Model Description of what the modeler believes to be relevant about a > system. 

Models may be developed based on > metamodels (Sect. 2.13). 

Modular architecture — Architecture of an information system where the > infor- 

mation system consists of more than one > application component. Synonym: 

AC” architecture (Sect. 3.6.2). 

Monitoring Task of > strategic management of information systems that continu- 

ously audits quality and cost of the information system and assesses whether the 

strategic information management plan is implemented as intended (Sect. 4.3.2). 

Monolithic architecture — Architecture of an information system where the > 
information system consists of only one > application component which sup- 
ports most of the > functions. Synonym: AC! architecture (Sect. 3.6.2). 

Non-computer-based application component Sets of organizational rules for 
data processing which are implemented by non-computer-based — physical 
tools. Specialization of > application component. Synonym: Paper-based appli- 
cation component (Sect. 2.9). 

Nursing management and documentation system (NMDS) — Application sys- 
tem supporting — functions related to organizing and documenting patients’ 
diagnostics and treatment from a nursing point of view (Sect. 3.4.2). 

Object identity Situation where all objects (> entities) can be uniquely and cor- 
rectly identified. In > health information systems, this is especially important 
for > entity types such as patient (— Patient Identification Number) and case 
(Case Identification Number) (Sect. 3.5). 

Open platform — Application system that stores patient —> data based on open 
specifications and open — information models and provides open Application 
Programming Interfaces (API) for storing and querying this data (Sect. 3.9.3) 

Operation management system (OMS) — Application system supporting > 
functions related to —> information processing of an operating room unit of a > 
health care facility (Sect. 3.4.8). 

Operational management of information systems Responsible for smooth oper- 
ation of the > components of the — information system in accordance with 
the — strategic information management plan. Additionally, it plans, directs, 
and monitors permanent — IT services for the users of the information system 
(Sect. 4.5). 

Organizational unit Part of a — health care facility which can be defined by 
responsibilities (Sect. 2.14.1). 

Paper-based application component See — non-computer-based application 
component (Sect. 2.9). 

Patient administration system (PAS) — Application system supporting — func- 

tions related to patient administration in — health care facilities. Synonym: 

Patient management system (Sect. 3.4.1). 
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Patient data management system (PDMS) — Application system supporting > 
functions related to > information processing in intensive care units of a > 
health care facility (Sect. 3.4.9). 

Patient identification number (PIN) Unique identification of a patient. Should be 
used for patient identification in all parts of a > health information system. One 
precondition for —> object identify (Sect. 3.2.3.1). 

Patient portal — Application system offered by > health care facilities that sup- 
ports patients of this facility to obtain an overview of their health data, organize 
documents, and actively manage these themselves (Sect. 3.4.13.1). 

Physical data processing system Physical entity that is able to receive, store, for- 
ward, or purposefully manipulate > data (Sect. 2.9). 

Physical integration Condition of an > information system in which the neces- 
sary physical communication between a set of — physical data processing sys- 
tems for each required data exchange is possible (Sect. 3.10.2). 

Physical interoperability Ability of — physical data processing systems to 
exchange — data via hardware interfaces. Prerequisite for > technical interoper- 
ability of > application systems (Sect. 3.10.2). 

Physical tool See — physical data processing system (Sect. 2.9). 

Physical tool layer Part of a > 3LGM? model. Describes > physical data process- 
ing systems and their data transmission links among each other (Sect. 2.14.3). 
Picture archiving and communication system (PACS) — Application system 
supporting the — functions related to storage, retrieval, management, manip- 
ulation, presentation, and communication of large amounts of digital images 

(Sect. 3.4.6). 

Planning Task of > strategic information management that comprises — strategic 
alignment of business goals and strategic information management goals, and 
the development of both a long-term — strategic project portfolio and —> annual 
project portfolios (Sect. 4.3.1). 

Process integration Condition of an > information system in which business pro- 
cesses are effectively supported by a set of interoperating — application systems 
(Sect. 3.8.6). 

Process interoperability Ability of > application systems to interoperate in cer- 
tain organizational contexts, especially in certain processes (Sect. 3.7.1.4). 

Project Unique undertaking that is characterized by objectives, by restrictions with 
regard to available time and resources, and by a specific project organization 
(Sect. 4.4). 

Protocol Standard for — technical interoperability at the —> physical tool layer for 
supporting communication between — computer systems (Sect. 3.7.1.1). 

Quality Degree to which a set of inherent characteristics fulfills certain require- 
ments, where “requirements” means needs or expectations (Sect. 5.1). 

Radiology information system (RIS) — Application system supporting > func- 
tions related to > information processing at the radiological unit of a > health 
care facility (Sect. 3.4.5). 

Reference model A model is called a reference model for a certain class of systems 
and a certain class of questions or tasks dealing with these systems if it provides 
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model patterns supporting the derivation of more specific models through modi- 
fications, limitations, or completions (generic reference models) or direct com- 
parison of different models with the reference model concerning certain quality 
aspects of the modeled systems (e.g., completeness, styles of system’s architec- 
ture) (non-generic reference models) (Sect. 2.13). 

Referential integrity Situation where relationships between — entities are correctly 
represented. A precondition for referential integrity is —> object identity (Sect. 3.5). 

Role Sum of expectations addressed to persons or groups of persons (Sect. 2.8). 

Semantic integration Condition of an > information system in which > applica- 
tion systems actually use the same system of concepts, for example, based on a 
common —> terminology, i.e., they interpret —> data the same way (Sect. 3.8.2). 

Semantic interoperability Ability of > application systems to exchange —> infor- 
mation (in the form of > messages) that can be meaningfully interpreted by both 
and processed further (Sect. 3.7.1.3). 

Service Encapsulated — feature provided by — application systems in order to be 
invoked by other application systems (Sect. 2.9). 

Service-level agreements (SLA) Contract regarding the provision of an > IT ser- 
vice, for example, between a department and the IT department (Sect. 5.2.4). 
Service-oriented architectures (SOA) — Architectural style of > health informa- 
tion systems where — application systems are able to provide or to invoke > 

services from other — application systems (Sect. 3.9.4). 

Socio-technical system A (human-made) > system consisting of both human and 
technical components (Sect. 2.5). 

Spaghetti architecture — Architecture of an information system where the > 
application systems are connected via bidirectional — communication links. 
Synonym: CP” architecture (Sect. 3.6.4). 

Stakeholder Anyone who has an influence on or specific requirement regarding a 
— component of an > information system, for example, by formulating require- 
ments (Sect. 1.3). 

Standardized documentation Documentation where the > entity types for which 
> data are to be recorded, the properties (attributes) of the —> objects of these > 
entity types that are to be documented, and the exact value set of these attributes 
are defined (Sect. 3.2.2). 

Star architecture — Architecture of an information system where the — applica- 
tion systems communicate via a central application system (e.g., a > communi- 
cation server). Synonym: CP! architecture (Sect. 3.6.4). 

Strategic alignment The process that balances and harmonizes the — business 
goals and the > information management strategies to obtain the best result for 
the — health care facility. Important task of > strategic information manage- 
ment (Sect. 4.3.1.1). 

Strategic information management plan Long-term planning of the > informa- 
tion system of a > health care facility. This plan describes the > business goals, 
the — information management goals, the current state of the information sys- 
tem, the future state of the information system, and the steps to transform the 
current into the planned information system (Sect. 4.3.1.2). 


Glossary 255 


Strategic management of information systems Deals with the — information 
processing as a whole and establishes strategies and principles for the evolution 
of the — information system. It depends on and must be aligned to the vision, 
mission, and strategic — business goals of the > health care facility (— strategic 
alignment). An important result of strategic management activities is a > strate- 
gic information management plan (Sect. 4.3). 

Strategic project portfolio Describes —> projects or groups of projects and their 
priority, and a rough timeline for their initiation for the coming years. It is 
typically described in a > strategic information management plan. Is the basis 
for the > annual project portfolio (Sect. 4.3.1.2). 

Sub-information system — Subsystem of an > information system (Sect. 2.5). 

Subsystem Part of a > system that comprises a subset of > components and the 
relationships between them (Sect. 2.4). 

Synchronous communication Form of communication in which the sending > 
application system will pause from the time that it sends a > message to the time 
that it receives the respective answer (Sect. 3.9.2). 

Syntactic interoperability Ability of > application systems to use a predefined 
structure for the exchanged — messages (Sect. 3.7.1.2). 

System Set of persons, things, events, and their relationships forming an integrated 
whole. We distinguish between natural systems and artificial (human-made) > 
socio-technical systems. A system can be divided into — subsystems (Sect. 2.4). 

Tactical management of information systems Deals with specific — functions, 
— application components, or > physical data processing systems that are intro- 
duced, removed, changed, or maintained. Usually, these activities are done in the 
form of > projects (Sect. 4.4). 

Technical interoperability Ability of an > application system to send or receive 
“bits and bytes” in a reliable and standardized way via respective interfaces and 
— protocols (Sect. 3.7.1.1). 

Terminology A system of concepts and related terms (Sect. 2.1). 

Three-layer graph-based metamodel (3LGM?) — Metamodel for modeling 
(health) > information systems (Sect. 2.14). 

Telemonitoring system — Application system supporting — functions related to 
the remote monitoring of the patients’ state of health (Sect. 3.4.13.2). 

Transaction management Ensures that every update of correct > data in one or 
more databases will lead to another state in which the data in these database(s) 
are still correct (Sect. 3.9.1). 

Transinstitutional health information system (tHIS) — Information system of a 
— health care network (Sect. 2.6). 

User interface integration Condition of an > information system in which differ- 
ent > application systems represent —> data and organize their user interfaces in 
a unified way (Sect. 3.8.3). 

V! architecture See —> homogeneous architecture (Sect. 3.6.3). 

V" architecture See — heterogeneous architecture (Sect. 3.6.3). 

Vendor-neutral archive (VNA) — Open platforms supporting storing of image 
data and other patient-related documents (Sect. 3.9.3). 
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